https://docs.moodle.org/dev/api.php?action=feedcontributions&feedformat=atom&user=Martinlanghoff 2026-04-12T08:02:01Z User contributions MediaWiki 1.43.5 https://docs.moodle.org/dev/index.php?title=Working_with_the_Community&diff=5595 2008-10-14T06:13:37Z

<p>Martinlanghoff: /* See also */</p> <hr /> <div>The goal of the Moodle community is to provide the best possible LMS there is. When you submit a patch (or new module, plugin or filter) for acceptance, it will be reviewed on its technical and educational merits and those alone. So, what should you be expecting?<br /> <br /> * criticism<br /> * comments<br /> * requests for change<br /> * requests for justification<br /> * silence<br /> * pointers to another subproject with the same goals<br /> <br /> Remember, this is part of getting your patch into Moodle. You have<br /> to be able to take criticism and comments about your patches, evaluate<br /> them at a technical level and either rework your patches or provide<br /> clear and concise reasoning as to why those changes should not be made.<br /> If there are no responses to your posting, wait a few days and try<br /> again, sometimes things get lost in the huge volume.<br /> <br /> What should you not do?<br /> * expect your patch to be accepted without question<br /> * become defensive<br /> * ignore comments<br /> * resubmit the patch without making any of the requested changes<br /> <br /> In a community that is looking for the best technical solution possible,<br /> there will always be differing opinions on how beneficial a patch is.<br /> You have to be cooperative, and willing to adapt your idea to fit within<br /> Moodle. Or at least be willing to prove your idea is worth it.<br /> Remember, being wrong is acceptable as long as you are willing to work<br /> toward a solution that is right.<br /> <br /> ==Differences between the Moodle community and corporate structures==<br /> <br /> The Moodle community works differently than most traditional corporate development environments. Here is a list of things that you can try to do to try to avoid problems:<br /> <br /> '''Good''' things to say regarding your proposed changes:<br /> * &quot;This works great with 9-year olds for learning X.&quot;<br /> * &quot;This solves multiple problems.&quot;<br /> * &quot;This deletes 2000 lines of code.&quot;<br /> * &quot;Here is a patch that explains what I am trying to describe.&quot;<br /> * &quot;I tested it on 5 different databases...&quot;<br /> * &quot;Here is a series of small patches that...&quot;<br /> * &quot;This increases performance on typical machines...&quot;<br /> <br /> '''Bad''' things you should avoid saying:<br /> * &quot;This educational theory supports my use model, even if I didn't test it with students&quot;<br /> * &quot;We did it this way in WebCT/Blackboard, so therefore it must begood...&quot;<br /> * &quot;I've being doing this for 20 years, so...&quot;<br /> * &quot;It makes this proprietary benchmark go faster&quot;<br /> * &quot;This is required for my company to make money&quot;<br /> * &quot;This is for our Enterprise product line.&quot;<br /> * &quot;Here is my 1000 page design document that describes my idea&quot;<br /> * &quot;I've been working on this for 6 months...&quot;<br /> * &quot;Here's a 5000 line patch that...&quot;<br /> * &quot;I rewrote all of the current mess, and here it is...&quot;<br /> * &quot;I have a deadline, and this patch needs to be applied now.&quot;<br /> <br /> Another way the Moodle community is different than most traditional<br /> software engineering work environments is the faceless nature of<br /> interaction. One benefit of using email and forums as the primary forms of<br /> communication is the lack of discrimination based on gender or race.<br /> The Moodle work environment is accepting of women and minorities<br /> because all you are is an email address. The international aspect also<br /> helps to level the playing field because you can't guess gender based on<br /> a person's name. A man may be named Andrea and a woman may be named Pat.<br /> <br /> The language barrier can cause problems for some people who are not<br /> comfortable with English. A good grasp of the language can be needed in<br /> order to get ideas across properly on forums, so it is<br /> recommended that you check your emails to make sure they make sense in<br /> English before sending them.<br /> <br /> ==Consider asking or discussing your proposal first==<br /> <br /> It is surprising how often a forum posting along the lines of &quot;I wish to propose xxxx&quot; <br /> can produce interesting results. You may find that somebody has 95% completed the thing<br /> you want to do. You may find somebody has done something similar that you can adapt. You <br /> may even have issues raised that you never thought of that may result in a change of direction<br /> or abandoning it altogether (a ''good thing'' as it can save hours of work). <br /> <br /> ==Break your changes up==<br /> <br /> The Moodle community does not gladly accept large chunks of code<br /> dropped on it all at once. The changes need to be properly introduced,<br /> discussed, and broken up into tiny, individual portions. This is almost<br /> the exact opposite of what companies are used to doing. Your proposal<br /> should also be introduced very early in the development process, so that<br /> you can receive feedback on what you are doing. It also lets the<br /> community feel that you are working with them, and not simply using them<br /> as a dumping ground for your feature. However, don't post 50 times at<br /> once in the forums! <br /> <br /> The reasons for breaking things up are the following:<br /> <br /> # Small patches increase the likelihood that your patches will be applied, since they don't take much time or effort to verify for correctness. A 5 line patch can be applied by a maintainer with barely a second glance. However, a 500 line patch may take hours to review for correctness (the time it takes is exponentially proportional to the size of the patch, or something). Small patches also make it very easy to debug when something goes wrong. It's much easier to back out patches one by one than it is to dissect a very large patch after it's been applied (and broken something).<br /> # It's important not only to send small patches, but also to rewrite and simplify (or simply re-order) patches before submitting them.<br /> <br /> It may be challenging to keep the balance between presenting an elegant<br /> solution and working together with the community and discuss your<br /> unfinished work. Therefore it is good to get early in the process to<br /> get feedback to improve your work, but also keep your changes in small<br /> chunks that they may get already accepted, even when your whole task is<br /> not ready for inclusion now.<br /> <br /> Also realize that it is not acceptable to send patches for inclusion<br /> that are unfinished and will be &quot;fixed up later.&quot;<br /> <br /> ==Justify your change==<br /> <br /> Along with breaking up your patches, it is very important for you to let<br /> the Moodle community know why they should add this change. New features<br /> must be justified as being needed and useful.<br /> <br /> ==See also==<br /> <br /> * [[How to create a patch]].<br /> * [http://www.linux-mips.org/wiki/The_perfect_patch The perfect patch] as seen by the Linux kernel developers<br /> [[Category:Working with the Community]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=User:Martin_Langhoff&diff=19901 2008-09-16T07:28:58Z

<p>Martinlanghoff: </p> <hr /> <div>[[Image:martin_langhoff.jpg|thumb|right|250px|Martin Langhoff @ Milford Sound]] <br /> [[Image:Martin_Langhoff-San_Francisco_Moot_olpc.jpg|thumb|right|250px|Martin Langhoff @ San Francisco Moot]] <br /> '''Core Moodle developer since 2004''', often blamed of tuning things for scalability and performance (mainly the v1.9, v1.4 and v1.5 releases) and servers, auth/enrolment plugins, MNET, PostgreSQL support and other trivia.<br /> <br /> = One Laptop per Child... and One Moodle per School! =<br /> <br /> Since March 2008 I am working on '''getting the School Server for OLPC ready for prime time'''. My title @ OLPC is ''architect'', but the job description is actually ''get it done''. Whether it is drawing pretty high level architecture plans, working with on-the-ground local teams on configuration, '''''hacking on Moodle''''' or getting dirty with OS-level programming, I am there. <br /> <br /> :Here is our [http://wiki.laptop.org/go/School_server#Roadmap XS roadmap].<br /> <br /> = Catalyst roots =<br /> <br /> Before joining OLPC, I started the e-learning team @ [http://catalyst.net.nz/moodle/ Catalyst IT], a [http://moodle.com/partners/ Moodle Partner], developing and customizing Moodle for institutions in New Zealand and around the world. A good part of the e-learning work was done under the [http://eduforge.org/projects/nzvle/ NZVLE] project, part of [http://eduforge.org/ Eduforge.org] (which is also one of my projects). <br /> <br /> Catalyst IT also has a lot of experience in the enterprise sector and high-scalability installations, with hundreds of thousands of users and courses. The team has some great people. You will see them posting in the Moodle forums often ;-)<br /> <br /> = Other projects =<br /> <br /> I also hack on other interesting projects:<br /> <br /> * Linus Torvalds' [http://git.or.cz GIT project] -- [http://kernel.org/git/?p=git%2Fgit.git&amp;a=search&amp;h=HEAD&amp;s=langhoff including the weird git-cvsserver]<br /> * [http://elgg.net/ Elgg] (not any more, try Mahara instead :-) )<br /> * [http://gforge.org GForge] (not any more)<br /> * [http://eprints.org EPrints] (not any more)<br /> <br /> My personal focus is on leading Linux-based development projects, using PHP, Perl, Apache, OpenLDAP, PostgreSQL, MySQL and a few other trinkets. At home, add books on media, psychology and postmodernism.<br /> <br /> In my spare time (?) I do some volunteer work for the Open Source community. When possible, I help [http://qa.debian.org/developer.php?login=martin%40nzl.com.ar Debian] and Ubuntu efforts. Unfortunately, I've missed the last few Debconfs.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=User:Martin_Langhoff&diff=19900 2008-09-16T07:26:46Z

<p>Martinlanghoff: </p> <hr /> <div>[[Image:martin_langhoff.jpg|thumb|right|250px|Martin Langhoff @ Milford Sound]] <br /> [[Image:Martin_Langhoff-San_Francisco_Moot_olpc.jpg|thumb|right|250px|Martin Langhoff @ San Francisco Moot]] <br /> '''Core Moodle developer since 2004''', often blamed for performance tuning of code (v1.9, v1.4, v1.5) and servers, auth/enrolment plugins, MNET, PostgreSQL support and other trivia.<br /> <br /> = One Laptop per Child... and One Moodle per School! =<br /> <br /> Since March 2008 I am working on '''getting the School Server for OLPC ready for prime time'''. My title @ OLPC is ''architect'', but the job description is actually ''get it done''. Whether it is drawing pretty high level architecture plans, working with on-the-ground local teams on configuration, '''''hacking on Moodle''''' or getting dirty with OS-level programming, I am there. <br /> <br /> :Here is our [http://wiki.laptop.org/go/School_server#Roadmap XS roadmap].<br /> <br /> = Catalyst roots =<br /> <br /> Before joining OLPC, I started the e-learning team @ [http://catalyst.net.nz/moodle/ Catalyst IT], a [http://moodle.com/partners/ Moodle Partner], developing and customizing Moodle for institutions in New Zealand and around the world. A good part of the e-learning work was done under the [http://eduforge.org/projects/nzvle/ NZVLE] project, part of [http://eduforge.org/ Eduforge.org] (which is also one of my projects). <br /> <br /> Catalyst IT also has a lot of experience in the enterprise sector and high-scalability installations, with hundreds of thousands of users and courses. The team has some great people. You will see them posting in the Moodle forums often ;-)<br /> <br /> = Other projects =<br /> <br /> I also hack on other interesting projects:<br /> <br /> * Linus Torvalds' [http://git.or.cz GIT project] -- [http://kernel.org/git/?p=git%2Fgit.git&amp;a=search&amp;h=HEAD&amp;s=langhoff including the weird git-cvsserver]<br /> * [http://elgg.net/ Elgg] (not any more, try Mahara instead :-) )<br /> * [http://gforge.org GForge] (not any more)<br /> * [http://eprints.org EPrints] (not any more)<br /> <br /> My personal focus is on leading Linux-based development projects, using PHP, Perl, Apache, OpenLDAP, PostgreSQL, MySQL and a few other trinkets. At home, add books on media, psychology and postmodernism.<br /> <br /> In my spare time (?) I do some volunteer work for the Open Source community. When possible, I help [http://qa.debian.org/developer.php?login=martin%40nzl.com.ar Debian] and Ubuntu efforts. Unfortunately, I've missed the last few Debconfs.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=User:Martin_Langhoff&diff=19899 2008-07-15T00:40:05Z

<p>Martinlanghoff: </p> <hr /> <div>[[Image:martin_langhoff.jpg|thumb|right|250px|Martin Langhoff @ Milford Sound]] <br /> [[Image:Martin_Langhoff-San_Francisco_Moot_olpc.jpg|thumb|right|250px|Martin Langhoff @ San Francisco Moot]] <br /> Core Moodle developer since 2004, often blamed for performance tuning of code (v1.9, v1.4, v1.5) and servers, auth/enrolment plugins, MNET, PostgreSQL support and other trivia.<br /> <br /> Since March 2008 I am working on '''getting the School Server for OLPC ready for prime time'''. My title @ OLPC is ''architect'', but the job description is actually ''get it done''. Whether it is drawing pretty high level architecture plans, working with on-the-ground teams on configuration or getting dirty with OS-level programming, I am there. Here is our [http://wiki.laptop.org/go/School_server#Roadmap XS roadmap].<br /> <br /> Before this, I started the e-learning team @ [http://catalyst.net.nz/moodle/ Catalyst IT], a [http://moodle.com/partners/ Moodle Partner], developing and customizing Moodle for tertiaries in New Zealand and around the world. A good part of the e-learning work was done under the [http://eduforge.org/projects/nzvle/ NZVLE] project, part of [http://eduforge.org/ Eduforge.org] (which is also one of my projects). <br /> <br /> Catalyst IT also has a lot of experience in the enterprise sector and high-scalability installations, with hundreds of thousands of users and courses. The team has some great people. You will see them posting in the Moodle forums often ;-)<br /> <br /> I also hack on other interesting projects:<br /> <br /> * Linus Torvalds' [http://git.or.cz GIT project] -- [http://kernel.org/git/?p=git%2Fgit.git&amp;a=search&amp;h=HEAD&amp;s=langhoff including the weird git-cvsserver]<br /> * [http://elgg.net/ Elgg]<br /> * [http://gforge.org GForge]<br /> * [http://eprints.org EPrints]<br /> <br /> My personal focus is on leading Linux-based development projects, using PHP, Perl, Apache, OpenLDAP, PostgreSQL, MySQL and a few other trinkets. At home, add books on media, psychology and postmodernism.<br /> <br /> In my spare time (?) I do some volunteer work for the Open Source community, particularly [http://qa.debian.org/developer.php?login=martin%40nzl.com.ar Debian].</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=User:Martin_Langhoff&diff=19898 2008-05-27T20:48:08Z

<p>Martinlanghoff: </p> <hr /> <div>[[Image:martin_langhoff.jpg|thumb|right|250px|Martin Langhoff @ Milford Sound]] <br /> <br /> Core Moodle developer since 2004, often blamed for performance tuning of code (v1.9, v1.4, v1.5) and servers, auth/enrolment plugins, MNET, PostgreSQL support and other trivia.<br /> <br /> Since March 2008 I am working on '''getting the School Server for OLPC ready for prime time'''. My title @ OLPC is ''architect'', but the job description is actually ''get it done''. Whether it is drawing pretty high level architecture plans, working with on-the-ground teams on configuration or getting dirty with OS-level programming, I am there. Here is our [http://wiki.laptop.org/go/School_server#Roadmap XS roadmap].<br /> <br /> Before this, I started the e-learning team @ [http://catalyst.net.nz/moodle/ Catalyst IT], a [http://moodle.com/partners/ Moodle Partner], developing and customizing Moodle for tertiaries in New Zealand and around the world. A good part of the e-learning work was done under the [http://eduforge.org/projects/nzvle/ NZVLE] project, part of [http://eduforge.org/ Eduforge.org] (which is also one of my projects). <br /> <br /> Catalyst IT also has a lot of experience in the enterprise sector and high-scalability installations, with hundreds of thousands of users and courses. The team has some great people. You will see them posting in the Moodle forums often ;-)<br /> <br /> I also hack on other interesting projects:<br /> <br /> * Linus Torvalds' [http://git.or.cz GIT project] -- [http://kernel.org/git/?p=git%2Fgit.git&amp;a=search&amp;h=HEAD&amp;s=langhoff including the weird git-cvsserver]<br /> * [http://elgg.net/ Elgg]<br /> * [http://gforge.org GForge]<br /> * [http://eprints.org EPrints]<br /> <br /> My personal focus is on leading Linux-based development projects, using PHP, Perl, Apache, OpenLDAP, PostgreSQL, MySQL and a few other trinkets. At home, add books on media, psychology and postmodernism.<br /> <br /> In my spare time (?) I do some volunteer work for the Open Source community, particularly [http://qa.debian.org/developer.php?login=martin%40nzl.com.ar Debian].</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=User:Martin_Langhoff&diff=19897 2008-05-27T20:44:49Z

<p>Martinlanghoff: </p> <hr /> <div>[[Image:martin_langhoff.jpg|thumb|right|250px|Martin Langhoff @ Milford Sound]] <br /> <br /> Core Moodle developer since 2004, often blamed for performance tuning of code and servers, auth/enrolment plugins, MNET and other trivia. <br /> <br /> Since March 2008 I am working on '''getting the School Server for OLPC ready for prime time'''. My title @ OLPC is ''architect'', but the job description is actually ''get it done''. Whether it is drawing pretty high level architecture plans, working with on-the-ground teams on configuration or getting dirty with OS-level programming, I am there. Here is our [http://wiki.laptop.org/go/School_server#Roadmap XS roadmap].<br /> <br /> Before this, I started the e-learning team @ [http://catalyst.net.nz/moodle/ Catalyst IT], a [http://moodle.com/partners/ Moodle Partner], developing and customizing Moodle for tertiaries in New Zealand and around the world. A good part of the e-learning work was done under the [http://eduforge.org/projects/nzvle/ NZVLE] project, part of [http://eduforge.org/ Eduforge.org] (which is also one of my projects). <br /> <br /> Catalyst IT also has a lot of experience in the enterprise sector and high-scalability installations, with hundreds of thousands of users and courses. The team has some great people. You will see them posting in the Moodle forums often ;-)<br /> <br /> I also hack on other interesting projects:<br /> <br /> * Linus Torvalds' [http://git.or.cz GIT project] -- [http://kernel.org/git/?p=git%2Fgit.git&amp;a=search&amp;h=HEAD&amp;s=langhoff including the weird git-cvsserver]<br /> * [http://elgg.net/ Elgg]<br /> * [http://gforge.org GForge]<br /> * [http://eprints.org EPrints]<br /> <br /> My personal focus is on leading Linux-based development projects, using PHP, Perl, Apache, OpenLDAP, PostgreSQL, MySQL and a few other trinkets. At home, add books on media, psychology and postmodernism.<br /> <br /> In my spare time (?) I do some volunteer work for the Open Source community, particularly [http://qa.debian.org/developer.php?login=martin%40nzl.com.ar Debian].</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=User:Martin_Langhoff&diff=19896 2008-03-22T02:04:45Z

<p>Martinlanghoff: </p> <hr /> <div>[[Image:martin_langhoff.jpg|thumb|right|250px|Martin Langhoff @ Milford Sound]] <br /> <br /> ::'''Note''' at this time (mid-March 2008) I am transitioning from leading the elearning team @ Catalyst to a new project: '''getting the School Server for OLPC ready for prime time'''. My new title is ''architect'', but the job description is actually ''get it done'', whether it is drawing pretty high level architecture plans or getting dirty with OS-level programming. I will be taking over from John Watlington as he shifts his focus towards the hardware side of the XS and XO) -- here is the [http://wiki.laptop.org/go/School_server#Roadmap XS roadmap] we have today.<br /> ::So the notes below are a bit outdated :-)<br /> <br /> I work @ [http://catalyst.net.nz/moodle/ Catalyst IT], a [http://moodle.com/partners/ Moodle Partner], developing and customizing Moodle for tertiaries in New Zealand. Most of our e-learning work was done under the [http://eduforge.org/projects/nzvle/ NZVLE] project, part of [http://eduforge.org/ Eduforge.org]. [http://eduforge.org/projects/nzvle/ NZVLE] is spearheading a lot of interesting e-learning projects - do get in touch!<br /> <br /> Catalyst IT also has a lot of experience in the enterprise sector and high-scalability installations, with hundreds of thousands of users and courses. The team has some great people. You will see us posting in the Moodle forums often ;-)<br /> <br /> I also hack on other interesting projects:<br /> <br /> * Linus Torvalds' [http://git.or.cz GIT project] -- [http://kernel.org/git/?p=git%2Fgit.git&amp;a=search&amp;h=HEAD&amp;s=langhoff including the weird git-cvsserver]<br /> * [http://elgg.net/ Elgg]<br /> * [http://gforge.org GForge]<br /> * [http://eprints.org EPrints]<br /> <br /> My personal focus is on leading Linux-based development projects, using PHP, Perl, Apache, OpenLDAP, PostgreSQL, MySQL and a few other trinkets. At home, add books on media, psychology and postmodernism.<br /> <br /> In my spare time (?) I do some volunteer work for the Open Source community, particularly [http://qa.debian.org/developer.php?login=martin%40nzl.com.ar Debian].</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Working_with_the_Community&diff=5594 2008-03-21T16:34:33Z

<p>Martinlanghoff: /* Differences between the Moodle community and corporate structures */</p> <hr /> <div>The goal of the Moodle community is to provide the best possible LMS there is. When you submit a patch (or new module, plugin or filter) for acceptance, it will be reviewed on its technical and educational merits and those alone. So, what should you be expecting?<br /> <br /> * criticism<br /> * comments<br /> * requests for change<br /> * requests for justification<br /> * silence<br /> * pointers to another subproject with the same goals<br /> <br /> Remember, this is part of getting your patch into Moodle. You have<br /> to be able to take criticism and comments about your patches, evaluate<br /> them at a technical level and either rework your patches or provide<br /> clear and concise reasoning as to why those changes should not be made.<br /> If there are no responses to your posting, wait a few days and try<br /> again, sometimes things get lost in the huge volume.<br /> <br /> What should you not do?<br /> * expect your patch to be accepted without question<br /> * become defensive<br /> * ignore comments<br /> * resubmit the patch without making any of the requested changes<br /> <br /> In a community that is looking for the best technical solution possible,<br /> there will always be differing opinions on how beneficial a patch is.<br /> You have to be cooperative, and willing to adapt your idea to fit within<br /> Moodle. Or at least be willing to prove your idea is worth it.<br /> Remember, being wrong is acceptable as long as you are willing to work<br /> toward a solution that is right.<br /> <br /> ==Differences between the Moodle community and corporate structures==<br /> <br /> The Moodle community works differently than most traditional corporate development environments. Here is a list of things that you can try to do to try to avoid problems:<br /> <br /> '''Good''' things to say regarding your proposed changes:<br /> * &quot;This works great with 9-year olds for learning X.&quot;<br /> * &quot;This solves multiple problems.&quot;<br /> * &quot;This deletes 2000 lines of code.&quot;<br /> * &quot;Here is a patch that explains what I am trying to describe.&quot;<br /> * &quot;I tested it on 5 different databases...&quot;<br /> * &quot;Here is a series of small patches that...&quot;<br /> * &quot;This increases performance on typical machines...&quot;<br /> <br /> '''Bad''' things you should avoid saying:<br /> * &quot;This educational theory supports my use model, even if I didn't test it with students&quot;<br /> * &quot;We did it this way in WebCT/Blackboard, so therefore it must begood...&quot;<br /> * &quot;I've being doing this for 20 years, so...&quot;<br /> * &quot;It makes this proprietary benchmark go faster&quot;<br /> * &quot;This is required for my company to make money&quot;<br /> * &quot;This is for our Enterprise product line.&quot;<br /> * &quot;Here is my 1000 page design document that describes my idea&quot;<br /> * &quot;I've been working on this for 6 months...&quot;<br /> * &quot;Here's a 5000 line patch that...&quot;<br /> * &quot;I rewrote all of the current mess, and here it is...&quot;<br /> * &quot;I have a deadline, and this patch needs to be applied now.&quot;<br /> <br /> Another way the Moodle community is different than most traditional<br /> software engineering work environments is the faceless nature of<br /> interaction. One benefit of using email and forums as the primary forms of<br /> communication is the lack of discrimination based on gender or race.<br /> The Moodle work environment is accepting of women and minorities<br /> because all you are is an email address. The international aspect also<br /> helps to level the playing field because you can't guess gender based on<br /> a person's name. A man may be named Andrea and a woman may be named Pat.<br /> <br /> The language barrier can cause problems for some people who are not<br /> comfortable with English. A good grasp of the language can be needed in<br /> order to get ideas across properly on forums, so it is<br /> recommended that you check your emails to make sure they make sense in<br /> English before sending them.<br /> <br /> ==Consider asking or discussing your proposal first==<br /> <br /> It is surprising how often a forum posting along the lines of &quot;I wish to propose xxxx&quot; <br /> can produce interesting results. You may find that somebody has 95% completed the thing<br /> you want to do. You may find somebody has done something similar that you can adapt. You <br /> may even have issues raised that you never thought of that may result in a change of direction<br /> or abandoning it altogether (a ''good thing'' as it can save hours of work). <br /> <br /> ==Break your changes up==<br /> <br /> The Moodle community does not gladly accept large chunks of code<br /> dropped on it all at once. The changes need to be properly introduced,<br /> discussed, and broken up into tiny, individual portions. This is almost<br /> the exact opposite of what companies are used to doing. Your proposal<br /> should also be introduced very early in the development process, so that<br /> you can receive feedback on what you are doing. It also lets the<br /> community feel that you are working with them, and not simply using them<br /> as a dumping ground for your feature. However, don't post 50 times at<br /> once in the forums! <br /> <br /> The reasons for breaking things up are the following:<br /> <br /> # Small patches increase the likelihood that your patches will be applied, since they don't take much time or effort to verify for correctness. A 5 line patch can be applied by a maintainer with barely a second glance. However, a 500 line patch may take hours to review for correctness (the time it takes is exponentially proportional to the size of the patch, or something). Small patches also make it very easy to debug when something goes wrong. It's much easier to back out patches one by one than it is to dissect a very large patch after it's been applied (and broken something).<br /> # It's important not only to send small patches, but also to rewrite and simplify (or simply re-order) patches before submitting them.<br /> <br /> It may be challenging to keep the balance between presenting an elegant<br /> solution and working together with the community and discuss your<br /> unfinished work. Therefore it is good to get early in the process to<br /> get feedback to improve your work, but also keep your changes in small<br /> chunks that they may get already accepted, even when your whole task is<br /> not ready for inclusion now.<br /> <br /> Also realize that it is not acceptable to send patches for inclusion<br /> that are unfinished and will be &quot;fixed up later.&quot;<br /> <br /> ==Justify your change==<br /> <br /> Along with breaking up your patches, it is very important for you to let<br /> the Moodle community know why they should add this change. New features<br /> must be justified as being needed and useful.<br /> <br /> ==See also==<br /> <br /> * [[How to create a patch]].<br /> * [http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt The perfect patch]<br /> [[Category:Working with the Community]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Working_with_the_Community&diff=5593 2008-03-21T16:32:31Z

<p>Martinlanghoff: </p> <hr /> <div>The goal of the Moodle community is to provide the best possible LMS there is. When you submit a patch (or new module, plugin or filter) for acceptance, it will be reviewed on its technical and educational merits and those alone. So, what should you be expecting?<br /> <br /> * criticism<br /> * comments<br /> * requests for change<br /> * requests for justification<br /> * silence<br /> * pointers to another subproject with the same goals<br /> <br /> Remember, this is part of getting your patch into Moodle. You have<br /> to be able to take criticism and comments about your patches, evaluate<br /> them at a technical level and either rework your patches or provide<br /> clear and concise reasoning as to why those changes should not be made.<br /> If there are no responses to your posting, wait a few days and try<br /> again, sometimes things get lost in the huge volume.<br /> <br /> What should you not do?<br /> * expect your patch to be accepted without question<br /> * become defensive<br /> * ignore comments<br /> * resubmit the patch without making any of the requested changes<br /> <br /> In a community that is looking for the best technical solution possible,<br /> there will always be differing opinions on how beneficial a patch is.<br /> You have to be cooperative, and willing to adapt your idea to fit within<br /> Moodle. Or at least be willing to prove your idea is worth it.<br /> Remember, being wrong is acceptable as long as you are willing to work<br /> toward a solution that is right.<br /> <br /> ==Differences between the Moodle community and corporate structures==<br /> <br /> The Moodle community works differently than most traditional corporate development environments. Here is a list of things that you can try to do to try to avoid problems:<br /> <br /> '''Good''' things to say regarding your proposed changes:<br /> * &quot;This solves multiple problems.&quot;<br /> * &quot;This deletes 2000 lines of code.&quot;<br /> * &quot;Here is a patch that explains what I am trying to describe.&quot;<br /> * &quot;I tested it on 5 different databases...&quot;<br /> * &quot;Here is a series of small patches that...&quot;<br /> * &quot;This increases performance on typical machines...&quot;<br /> <br /> '''Bad''' things you should avoid saying:<br /> * &quot;We did it this way in WebCT/Blackboard, so therefore it must begood...&quot;<br /> * &quot;I've being doing this for 20 years, so...&quot;<br /> * &quot;It makes this proprietary benchmark go faster&quot;<br /> * &quot;This is required for my company to make money&quot;<br /> * &quot;This is for our Enterprise product line.&quot;<br /> * &quot;Here is my 1000 page design document that describes my idea&quot;<br /> * &quot;I've been working on this for 6 months...&quot;<br /> * &quot;Here's a 5000 line patch that...&quot;<br /> * &quot;I rewrote all of the current mess, and here it is...&quot;<br /> * &quot;I have a deadline, and this patch needs to be applied now.&quot;<br /> <br /> Another way the Moodle community is different than most traditional<br /> software engineering work environments is the faceless nature of<br /> interaction. One benefit of using email and forums as the primary forms of<br /> communication is the lack of discrimination based on gender or race.<br /> The Moodle work environment is accepting of women and minorities<br /> because all you are is an email address. The international aspect also<br /> helps to level the playing field because you can't guess gender based on<br /> a person's name. A man may be named Andrea and a woman may be named Pat.<br /> <br /> The language barrier can cause problems for some people who are not<br /> comfortable with English. A good grasp of the language can be needed in<br /> order to get ideas across properly on forums, so it is<br /> recommended that you check your emails to make sure they make sense in<br /> English before sending them.<br /> <br /> ==Consider asking or discussing your proposal first==<br /> <br /> It is surprising how often a forum posting along the lines of &quot;I wish to propose xxxx&quot; <br /> can produce interesting results. You may find that somebody has 95% completed the thing<br /> you want to do. You may find somebody has done something similar that you can adapt. You <br /> may even have issues raised that you never thought of that may result in a change of direction<br /> or abandoning it altogether (a ''good thing'' as it can save hours of work). <br /> <br /> ==Break your changes up==<br /> <br /> The Moodle community does not gladly accept large chunks of code<br /> dropped on it all at once. The changes need to be properly introduced,<br /> discussed, and broken up into tiny, individual portions. This is almost<br /> the exact opposite of what companies are used to doing. Your proposal<br /> should also be introduced very early in the development process, so that<br /> you can receive feedback on what you are doing. It also lets the<br /> community feel that you are working with them, and not simply using them<br /> as a dumping ground for your feature. However, don't post 50 times at<br /> once in the forums! <br /> <br /> The reasons for breaking things up are the following:<br /> <br /> # Small patches increase the likelihood that your patches will be applied, since they don't take much time or effort to verify for correctness. A 5 line patch can be applied by a maintainer with barely a second glance. However, a 500 line patch may take hours to review for correctness (the time it takes is exponentially proportional to the size of the patch, or something). Small patches also make it very easy to debug when something goes wrong. It's much easier to back out patches one by one than it is to dissect a very large patch after it's been applied (and broken something).<br /> # It's important not only to send small patches, but also to rewrite and simplify (or simply re-order) patches before submitting them.<br /> <br /> It may be challenging to keep the balance between presenting an elegant<br /> solution and working together with the community and discuss your<br /> unfinished work. Therefore it is good to get early in the process to<br /> get feedback to improve your work, but also keep your changes in small<br /> chunks that they may get already accepted, even when your whole task is<br /> not ready for inclusion now.<br /> <br /> Also realize that it is not acceptable to send patches for inclusion<br /> that are unfinished and will be &quot;fixed up later.&quot;<br /> <br /> ==Justify your change==<br /> <br /> Along with breaking up your patches, it is very important for you to let<br /> the Moodle community know why they should add this change. New features<br /> must be justified as being needed and useful.<br /> <br /> ==See also==<br /> <br /> * [[How to create a patch]].<br /> * [http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt The perfect patch]<br /> [[Category:Working with the Community]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=User:Martin_Langhoff&diff=19895 2008-03-10T05:20:09Z

<p>Martinlanghoff: </p> <hr /> <div>[[Image:martin_langhoff.jpg|thumb|right|250px|Martin Langhoff @ Milford Sound]] Hi, I am a programmer. <br /> <br /> ::'''Note''' these weeks I am transitioning from leading the elearning team @ Catalyst to a new &quot;little&quot; project: '''getting the School Server for OLPC ready for prime time'''. My new title is ''architect'', but the job description is actually ''get it done'', whether it is drawing pretty high level architecture plans or getting dirty with OS-level programming. I will be taking over from John Watlington as he shifts his focus towards the hardware side of the XS and XO) -- here is the [http://wiki.laptop.org/go/School_server XS roadmap] we have today.<br /> ::So the notes below are a bit outdated :-)<br /> <br /> I work @ [http://catalyst.net.nz/moodle/ Catalyst IT], a [http://moodle.com/partners/ Moodle Partner], developing and customizing Moodle for tertiaries in New Zealand. Most of our e-learning work was done under the [http://eduforge.org/projects/nzvle/ NZVLE] project, part of [http://eduforge.org/ Eduforge.org]. [http://eduforge.org/projects/nzvle/ NZVLE] is spearheading a lot of interesting e-learning projects - do get in touch!<br /> <br /> Catalyst IT also has a lot of experience in the enterprise sector and high-scalability installations, with hundreds of thousands of users and courses. The team has some great people. You will see us posting in the Moodle forums often ;-)<br /> <br /> I also hack on other interesting projects:<br /> <br /> * Linus Torvalds' [http://git.or.cz GIT project] -- [http://kernel.org/git/?p=git%2Fgit.git&amp;a=search&amp;h=HEAD&amp;s=langhoff including the weird git-cvsserver]<br /> * [http://elgg.net/ Elgg]<br /> * [http://gforge.org GForge]<br /> * [http://eprints.org EPrints]<br /> <br /> My personal focus is on leading Linux-based development projects, using PHP, Perl, Apache, OpenLDAP, PostgreSQL, MySQL and a few other trinkets. At home, add books on media, psychology and postmodernism.<br /> <br /> In my spare time (?) I do some volunteer work for the Open Source community, particularly [http://qa.debian.org/developer.php?login=martin%40nzl.com.ar Debian].</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=User:Martin_Langhoff&diff=19894 2008-03-10T05:19:58Z

<p>Martinlanghoff: </p> <hr /> <div>[[Image:martin_langhoff.jpg|thumb|right|250px|Martin Langhoff @ Milford Sound]] Hi, I am a programmer. <br /> <br /> ::'''Note''' these weeks I am transitioning from leading the elearning team @ Catalyst to a new &quot;little&quot; project: '''getting the School Server for OLPC ready for prime time'''. My new title is ''architect'', but the job description is actually ''get it done'', whether it is drawing pretty high level architecture plans or getting dirty with OS-level programming. I will be taking over from John Watlington as he shifts his focus towards the hardware side of the XS and XO) -- here is the [http://wiki.laptop.org/go/School_server XS roadmap] we have today.<br /> ::So the notes below are a bit outdated :-)<br /> <br /> I work @ [http://catalyst.net.nz/moodle/ Catalyst IT], a [http://moodle.com/partners/ Moodle Partner], developing and customizing Moodle for tertiaries in New Zealand. Most of our e-learning work was done under the [http://eduforge.org/projects/nzvle/ NZVLE] project, part of [http://eduforge.org/ Eduforge.org]. [http://eduforge.org/projects/nzvle/ NZVLE] is spearheading a lot of interesting e-learning projects - do get in touch ;-)<br /> <br /> Catalyst IT also has a lot of experience in the enterprise sector and high-scalability installations, with hundreds of thousands of users and courses. The team has some great people. You will see us posting in the Moodle forums often ;-)<br /> <br /> I also hack on other interesting projects:<br /> <br /> * Linus Torvalds' [http://git.or.cz GIT project] -- [http://kernel.org/git/?p=git%2Fgit.git&amp;a=search&amp;h=HEAD&amp;s=langhoff including the weird git-cvsserver]<br /> * [http://elgg.net/ Elgg]<br /> * [http://gforge.org GForge]<br /> * [http://eprints.org EPrints]<br /> <br /> My personal focus is on leading Linux-based development projects, using PHP, Perl, Apache, OpenLDAP, PostgreSQL, MySQL and a few other trinkets. At home, add books on media, psychology and postmodernism.<br /> <br /> In my spare time (?) I do some volunteer work for the Open Source community, particularly [http://qa.debian.org/developer.php?login=martin%40nzl.com.ar Debian].</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=User:Martin_Langhoff&diff=19893 2008-03-10T05:17:05Z

<p>Martinlanghoff: </p> <hr /> <div>[[Image:martin_langhoff.jpg|thumb|right|250px|Martin Langhoff @ Milford Sound]] Hi, I am a programmer. <br /> <br /> ::'''Note''' these weeks I am transitioning from leading the elearning team @ Catalyst to a new &quot;little&quot; project: '''getting the School Server for OLPC ready for prime time'''. My new title is ''architect'', but the job description is actually ''get it done'', whether it is drawing pretty high level architecture plans or getting dirty with OS-level programming. I will be taking over from John Watlington as he shifts his focus towards the hardware side of the XS and XO) -- here is the [http://wiki.laptop.org/go/School_server XS roadmap] we have today.<br /> ::So the notes below are a bit outdated :-)<br /> <br /> I work @ [http://catalyst.net.nz/moodle/ Catalyst IT], a [http://moodle.com/partners/ Moodle Partner], developing and customizing Moodle for tertiaries in New Zealand. Most of our e-learning work was done under the [http://eduforge.org/projects/nzvle/ NZVLE] project, part of [http://eduforge.org/ Eduforge.org]. [http://eduforge.org/projects/nzvle/ NZVLE] is spearheading a lot of interesting e-learning projects. <br /> <br /> Catalyst IT also has a lot of experience in the enterprise sector and high-scalability installations, with hundreds of thousands of users and courses. The team has some great people. You will see us posting in the Moodle forums often ;-)<br /> <br /> I also hack on other interesting projects:<br /> <br /> * Linus Torvalds' [http://git.or.cz GIT project] -- [http://kernel.org/git/?p=git%2Fgit.git&amp;a=search&amp;h=HEAD&amp;s=langhoff including the weird git-cvsserver]<br /> * [http://elgg.net/ Elgg]<br /> * [http://gforge.org GForge]<br /> * [http://eprints.org EPrints]<br /> <br /> My personal focus is on leading Linux-based development projects, using PHP, Perl, Apache, OpenLDAP, PostgreSQL, MySQL and a few other trinkets. At home, add books on media, psychology and postmodernism.<br /> <br /> In my spare time (?) I do some volunteer work for the Open Source community, particularly [http://qa.debian.org/developer.php?login=martin%40nzl.com.ar Debian].</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=User:Martin_Langhoff&diff=19892 2008-03-10T04:58:14Z

<p>Martinlanghoff: </p> <hr /> <div>[[Image:martin_langhoff.jpg|thumb|left|250px|Martin Langhoff @ Milford Sound]] Hi, I am a programmer. <br /> <br /> I work @ [http://catalyst.net.nz/moodle/ Catalyst IT], a [http://moodle.com/partners/ Moodle Partner], developing and customizing Moodle for tertiaries in New Zealand. Most of our e-learning work is done under the [http://eduforge.org/projects/nzvle/ NZVLE] project, part of [http://eduforge.org/ Eduforge.org]. [http://eduforge.org/projects/nzvle/ NZVLE] is spearheading a lot of interesting e-learning projects, get in touch!<br /> <br /> Catalyst IT also has a lot of experience in the enterprise sector and high-scalability installations, with hundreds of thousands of users and courses. The team has some great people, with Penny Leach, Jun Yamog, Greg Sutton, Peter Bulmer and a host of others here at Catalyst. You will see us posting in the Moodle forums often.<br /> <br /> I also hack on other interesting projects:<br /> <br /> * Linus Torvalds' [http://git.or.cz GIT project] -- [http://kernel.org/git/?p=git%2Fgit.git&amp;a=search&amp;h=HEAD&amp;s=langhoff including the weird git-cvsserver]<br /> * [http://elgg.net/ Elgg]<br /> * [http://gforge.org GForge]<br /> * [http://eprints.org EPrints]<br /> <br /> My personal focus is on leading Linux-based development projects, using PHP, Perl, Apache, OpenLDAP, PostgreSQL, MySQL and a few other trinkets. At home, add books on media, psychology and postmodernism.<br /> <br /> In my spare time (?) I do some volunteer work for the Open Source community, particularly [http://qa.debian.org/developer.php?login=martin%40nzl.com.ar Debian].</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=User:Martin_Langhoff&diff=19891 2008-03-10T04:53:47Z

<p>Martinlanghoff: </p> <hr /> <div>[[Image:martin_langhoff.jpg|thumb|left|250px|Martin Langhoff @ Milford Sound]] Hi, I am a programmer. <br /> <br /> I work @ [http://catalyst.net.nz/var/cm/cm-moodle.php Catalyst IT], a [http://moodle.com/partners/ Moodle Partner], developing and customizing Moodle for tertiaries in New Zealand. Most of our e-learning work is done under the [http://eduforge.org/projects/nzvle/ NZVLE] project, part of [http://eduforge.org/ Eduforge.org]. [http://eduforge.org/projects/nzvle/ NZVLE] is spearheading a lot of interesting e-learning projects, get in touch!<br /> <br /> Catalyst IT also has a lot of experience in the enterprise sector and high-scalability installations, with hundreds of thousands of users and courses. The team has some great people, with Penny Leach, Jun Yamog, Greg Sutton, Peter Bulmer and a host of others here at Catalyst. You will see us posting in the Moodle forums often.<br /> <br /> I also hack on other interesting projects:<br /> <br /> * Linus Torvalds' [http://git.or.cz GIT project] -- [http://kernel.org/git/?p=git%2Fgit.git&amp;a=search&amp;h=HEAD&amp;s=langhoff including the weird git-cvsserver]<br /> * [http://elgg.net/ Elgg]<br /> * [http://gforge.org GForge]<br /> * [http://eprints.org EPrints]<br /> <br /> My personal focus is on leading Linux-based development projects, using PHP, Perl, Apache, OpenLDAP, PostgreSQL, MySQL and a few other trinkets. At home, add books on media, psychology and postmodernism.<br /> <br /> In my spare time (?) I do some volunteer work for the Open Source community, particularly [http://qa.debian.org/developer.php?login=martin%40nzl.com.ar Debian].</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Overview&diff=7015 2008-01-22T02:33:35Z

<p>Martinlanghoff: /* How can you become a Moodle developer? */</p> <hr /> <div>A lot of people ask how the development of Moodle operates. This page should give you a working overview that should help in understanding a lot of other developer documentation.<br /> <br /> (This page is under early construction, your help in linking to other pages from here would be welcome!)<br /> <br /> ==The key players==<br /> <br /> ;Martin Dougiamas: Martin is the lead developer of Moodle. Generally he tries to facilitate democracy and meritocracy but occasionally has to make executive decisions on things.<br /> <br /> ;Moodle HQ: The mostly-Australian team of developers who are directly funded by the Moodle project to work full-time on core developments. Developers include Martin Dougiamas (moodler), Yu Zhang (lazyfish), Petr Skoda (skodak), Nicolas Connault, Helen Foster (wildgirl) and occasionally Eloy Lafuente (stronk7), Jamie Pratt (jamiesensei).<br /> <br /> ;Catalyst: The team of developers working for Moodle clients via Catalyst Ltd in New Zealand, resulting in a lot of core development. Developers include Martin Langhoff, Penny Leach (mjollnir), Matt Clarkson, and Donal McMullan.<br /> <br /> ;Open University: The team of developers working on Moodle implementations at Open University in the UK. Developers include Tim Hunt, Sam Marshall, Nick Freear, Thanh Le and Jenny Gray.<br /> <br /> There are many other people contributing to Moodle in many ways, these are just the main groups currently working on core development.<br /> <br /> ==Moodle versions==<br /> <br /> Moodle major releases occur roughly 6 months or more apart, on no fixed schedule. Each major release increments the version number by 0.1. Minor releases (no new features, just fixes) on each stable branch can occur at any time, whenever enough bug fixes have been made to justify them. The full details can be seen in the [[Release notes]].<br /> <br /> The current development version is always on the trunk of CVS (i.e. HEAD), while stable branches are split off for every major version (e.g. MOODLE_18_STABLE).<br /> <br /> <br /> ==Release cycles==<br /> <br /> Generally a cycle works like this:<br /> ;Rapid Development:Long period of several months adding code to the HEAD version of Moodle. At the same time, all fixes that don't involve database changes or radical core changes are backported to the last two or three stable branches.<br /> ;Head Freeze:At some point Martin Dougiamas declares a freeze on new work for a while to stabilise the core. All database changes and all major core changes need to have explicit permission from Martin. All developers should be wrapping up work on new features and fixing bugs in new code. This period may be 1 or 2 weeks.<br /> ;Beta period:Once the HEAD version becomes fairly stable, Martin declares a BETA version and this point is marked on HEAD as MOODLE_XX_BETA (e.g. MOODLE_19_BETA). Install packages are generated daily from the latest version for wider testing and feedback via the tracker. The freeze continues, testing and bug fixing continues. This testing period may be anywhere from 2 to 6 weeks.<br /> ;Major release:When the core code passes all the testing we can throw at it, the MOODLE_XX_BETA flag is moved up to mark the current point as a branch point, and a new stable branch named MOODLE_XX_STABLE is created. Packages are created, and the release is announced.<br /> <br /> Then it all starts again!<br /> <br /> ==Quality control==<br /> <br /> Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called the [[Tracker]].<br /> <br /> All Moodle users are encouraged to be active participants when it comes to testing. Anyone with a Tracker user account can create, view, comment on, vote, and watch bugs.<br /> <br /> ===Testers===<br /> <br /> Testers are responsible for verifying the accuracy of changes made by developers. Testers choose which bugs they want to test, according to their area of expertise, and use the QA Assignee field to identify themselves as the tester.<br /> <br /> If the bug passes testing, then the tester changes the status of the bug from 'resolved' to 'closed'. If the bug fails testing, or if the fix is incomplete, then the tester reopens the bug.<br /> <br /> A Moodle release will be deemed ready when all &quot;blocker&quot; bugs fixed for a particular version have been closed.<br /> <br /> ==Coding Standards==<br /> <br /> The full [[Coding|Coding Guide]] gives all the details, but here are some of the major things your code needs to hit:<br /> <br /> ===XMLDB===<br /> <br /> All our database schema are created using the XML ''install.php'' files, and upgraded using database-agnostic commands in ''upgrade.php'' files. Any version of any part of Moodle can be smoothly upgraded to any later version in this fashion (on a wide variety of supported databases).<br /> <br /> ===XHTML===<br /> <br /> All output from Moodle must be compliant with XHTML Strict 1.0, and also compliant with all common accessibility guidelines (such as W3C WAG). <br /> <br /> ===Forms===<br /> <br /> All forms should use the Moodleforms library if possible. This results in a standardised accessible output that designers can style consistently and well.<br /> <br /> ===Parameters===<br /> <br /> All parameters should be checked using require_param() and optional_param() which will safely clean all incoming data for use and provide defaults to your code. Moodleforms will do this automatically for you.<br /> <br /> ===Output===<br /> <br /> All textual output should be output using the format_text or format_string functions. This will ensure that text is cleaned and filtered appropriately.<br /> <br /> ===Access===<br /> <br /> All permissions-checking should use the &quot;Access library&quot; to check against current capabilities. The most common function you'll use is has_capability() which checks the permissions of the current user in an efficient way to see if they are allowed to do this specific operation. Do not check for specific roles in your code (e.g. teacher/student) as that will make your code useless.<br /> <br /> ===Other core libraries===<br /> <br /> The other major libraries you should get familiar with are:<br /> # ''moodlelib.php'' - a useful bin of all kinds of useful functions and constants<br /> # ''datalib.php'' - all the functions you need to interface with the database <br /> # ''weblib.php'' - all the functions you'll need to create and output XHTML <br /> <br /> <br /> ===Plugins===<br /> <br /> Moodle has about 22 different types of plugins last time I counted. Plugins can generally be self-contained in a single directory containing scripts, images, stylesheets and language files all in one package that can be dropped into the Moodle script directory in the right place. After that the admin just needs to visit the admin page to install them.<br /> <br /> Most plugins work in one of two ways, they either provide a ''lib.php'' filled with common functions and some scripts with standard names, or they subclass a proto-plugin and override a few method functions to achieve their goals. <br /> <br /> The best way to learn is to pick an example from the core code that is similar to what you want to do and start playing with it. There are also some template plugins to help get you started.<br /> <br /> ==Development processes==<br /> Not all Moodle development happens exactly like this, but it really should. :-)<br /> <br /> ===Major Development===<br /> A major development is a significant piece of new code, adding new functionality to Moodle.<br /> <br /> ====Make sure it's a good idea====<br /> Firstly, you should look at the roadmap and talk the idea over with some Moodle developers to see if someone else is working on it already and whether others think the general idea has merit. Use the forums if you wish, or whatever means you have. If you have a client, you may need to work with them to work out what they REALLY want (perhaps it isn't actually a new development for Moodle).<br /> <br /> ====Create a specification in Moodle Docs====<br /> Start a new page in the Moodle Docs wiki, similar to [[Grades]]. Your page should outline the database table design, the GUI, the hows and whys etc. Include as much detail as you need (even mock screenshots) but try to keep it clear and logically organised.<br /> <br /> ====Seek and absorb community feedback====<br /> Post about the new page in the appropriate forums on [http://moodle.org/course/view.php?id=5 Using Moodle] to help draw attention to it and to stimulate some discussion around your development. The more feedback you have the better, especially if it includes a wide variety of users (developers, teachers, students etc).<br /> <br /> Edit your page in response to the feedback, or invite people to do so themselves. try to evolve the specification into something that all users are happy with. Sometimes it's worth working harder to find the &quot;best&quot; way to do something without adding Yet Another Option.<br /> <br /> ====Set up tasks in the Moodle Tracker====<br /> Once the specification has settled down, it's time to start work. Create a new task for yourself in the Moodle Tracker, and add sub-tasks in roughly chronological order for all the different parts of the job. This not only helps you keep track of where you are, but allows the community to &quot;watch you&quot; develop and to help you where they can. If there are different people working on different parts, you can assign subtasks to different people. It's really very convenient to use once you get the hang of it.<br /> <br /> ====Use CVS and link commits to Tracker====<br /> If possible, develop the code in an open code repository (and preferably Moodle CVS!). If you need CVS write access to the core code or the contrib repository, contact support@moodle.com with details. Gaining access to the main core code is quite difficult, but we are generally very free with access to the contrib area.<br /> <br /> Every time you make a commit, include a detailed message about the new code and always include a Moodle Tracker bug number (e.g. MDL-7777). This will ensure that the Moodle Tracker is able to detect your commit and attach it to the relevant bug report.<br /> <br /> ====Comment on milestones in forums and tracker====<br /> If you hit a major milestone, or want testers to try something, feel free to post about it in the relevant forum on Using Moodle. The more people you can attract to look and try out your code the better it will be, trust me.<br /> <br /> ====Respond to bug reports====<br /> Of course you need to listen to your users (well, most of them :-)). Encourage people to file bugs, and fix them. If you need help setting up a project category in the Tracker contact support@moodle.com. This will ensure that all your bugs are easy to find and to track.<br /> <br /> ===Minor Development=== <br /> <br /> For smaller modules, fixes, improvements and other issues.<br /> <br /> ====Create a new issue in the tracker====<br /> <br /> You should definitely create an issue in the tracker to describe your development and to act as a focus point for all discussion. You can reference the bug number from forum discussions and in commit messages etc. This way everyone can easily find out exactly what they are talking about.<br /> <br /> ====Attach a patch====<br /> <br /> If you have some code, please attach it to the tracker issue, or if it's on your own site then link to it from the tracker issue. Don't attach code in the Moodle forums ... it will &quot;rot&quot; quickly there and just clogs up moodle.org with useless old code.<br /> <br /> ====Promote the patch====<br /> <br /> By all means draw attention to your work in the Moodle forums (mentioning the bug number) or email developers directly to help make them aware of it. You can also add developers as &quot;watchers&quot; to the tracker issue if you want, this means they will get email for every change on the issue.<br /> <br /> ==See also==<br /> <br /> * [[Finding your way into the Moodle code]]<br /> * [[Working with the Community]]<br /> <br /> [[Category:Overview]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Fast_portable_SQL&diff=7781 2008-01-14T20:44:52Z

<p>Martinlanghoff: /* Portable examples */</p> <hr /> <div>This is a work in progress! We keep notes here of bits of SQL that we know that<br /> <br /> * Work on all supported DBs (this is tricky!)<br /> * Are scalable and fast<br /> <br /> A key strategy for scalability is to ensure we do as much work as possible in the DB with minimal back-and-forth with PHP. Modern DB engines have very smart optimizers and if we play to their strenghts, can process millions of records in milliseconds. To hit those strenghts we want to reduce chattiness with the DB -- one &quot;smart&quot; SQL query (even if complex) is thousand of times better than a foreach loop in PHP that issues a thousand SQL queries. At least it will be more than a thousand times faster ;-)<br /> <br /> <br /> =UPDATE with JOINs=<br /> <br /> A good scalable way to update a lot of data is to combine the UPDATE with a SUBSELECT, to UPDATE the data directly from the DB itself. The rows never need to go back and forth to PHP, so this is extremely fast. The problem is that it is very hard to get it portable across DBs.<br /> <br /> Problems<br /> <br /> * Pg and MySQL disagree on the extended syntax of UPDATE with JOIN<br /> * MySQL does not support to have the table being updated in a subselect (but it supports it as JOINed table with a different alias - Pg does not support this)<br /> <br /> ==Portable examples==<br /> <br /> Fix a broken relation - this is roughly equivalent to a subselect with a LEFT OUTER JOIN:<br /> <br /> UPDATE {$CFG-&gt;prefix}course <br /> SET category = $defaultcategory<br /> WHERE<br /> NOT EXISTS (SELECT id FROM {$CFG-&gt;prefix}course_categories WHERE id={$CFG-&gt;prefix}course.category)<br /> AND {$CFG-&gt;prefix}course.id != $SITEID<br /> <br /> Delete chat_messages older than the (optional) keepdays setting in the related table chat. chat.keepdays the setting can be NULL or 0, both of which mean 'keep forever', so we have to be careful. This is somewhat clunky, but replaces hundreds of queries with 1. Notes...<br /> <br /> * If the subselect returns NULL or 0 it won't satisfy '&gt;0' - so we handle both cases in one check<br /> * We substract $keepdays - 24 * 3600 ... if we add it we can sometimes exceed the boundaries of an int in PostgreSQL<br /> * Could be improved to run the subselect only once<br /> ** Is there any DB that won't optimize this?<br /> ** How can we do this portably?<br /> * The subselect works on MySQL because it does not refer to the table we are deleting from<br /> <br /> $subselect = &quot;SELECT c.keepdays<br /> FROM {$CFG-&gt;prefix}chat c<br /> WHERE c.id = {$CFG-&gt;prefix}chat_messages.chatid&quot;;<br /> $sql = &quot;DELETE<br /> FROM {$CFG-&gt;prefix}chat_messages<br /> WHERE ($subselect) &gt; 0 AND timestamp &lt; ( &quot;.time().&quot; -($subselect) * 24 * 3600)&quot;;</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Fast_portable_SQL&diff=7779 2008-01-14T05:41:02Z

<p>Martinlanghoff: /* UPDATE with JOINs */</p> <hr /> <div>This is a work in progress! We keep notes here of bits of SQL that we know that<br /> <br /> * Work on all supported DBs (this is tricky!)<br /> * Are scalable and fast<br /> <br /> A key strategy for scalability is to ensure we do as much work as possible in the DB with minimal back-and-forth with PHP. Modern DB engines have very smart optimizers and if we play to their strenghts, can process millions of records in milliseconds. To hit those strenghts we want to reduce chattiness with the DB -- one &quot;smart&quot; SQL query (even if complex) is thousand of times better than a foreach loop in PHP that issues a thousand SQL queries. At least it will be more than a thousand times faster ;-)<br /> <br /> <br /> =UPDATE with JOINs=<br /> <br /> A good scalable way to update a lot of data is to combine the UPDATE with a SUBSELECT, to UPDATE the data directly from the DB itself. The rows never need to go back and forth to PHP, so this is extremely fast. The problem is that it is very hard to get it portable across DBs.<br /> <br /> Problems<br /> <br /> * Pg and MySQL disagree on the extended syntax of UPDATE with JOIN<br /> * MySQL does not support to have the table being updated in a subselect (but it supports it as JOINed table with a different alias - Pg does not support this)<br /> <br /> ==Portable examples==<br /> <br /> Fix a broken relation - this is roughly equivalent to a subselect with a LEFT OUTER JOIN:<br /> <br /> UPDATE {$CFG-&gt;prefix}course <br /> SET category = $defaultcategory<br /> WHERE<br /> NOT EXISTS (SELECT id FROM {$CFG-&gt;prefix}course_categories WHERE id={$CFG-&gt;prefix}course.category)<br /> AND mdl_course.id != $SITEID<br /> <br /> Delete chat_messages older than the (optional) keepdays setting in the related table chat. chat.keepdays the setting can be NULL or 0, both of which mean 'keep forever', so we have to be careful. This is somewhat clunky, but replaces hundreds of queries with 1. Notes...<br /> <br /> * If the subselect returns NULL or 0 it won't satisfy '&gt;0' - so we handle both cases in one check<br /> * We substract $keepdays - 24 * 3600 ... if we add it we can sometimes exceed the boundaries of an int in PostgreSQL<br /> * Could be improved to run the subselect only once<br /> ** Is there any DB that won't optimize this?<br /> ** How can we do this portably?<br /> * The subselect works on MySQL because it does not refer to the table we are deleting from<br /> <br /> $keepdays = &quot;SELECT c.keepdays<br /> FROM {$CFG-&gt;prefix}chat c<br /> WHERE c.id = {$CFG-&gt;prefix}chat_messages.chatid&quot;;<br /> $sql = &quot;DELETE<br /> FROM {$CFG-&gt;prefix}chat_messages<br /> WHERE ($subselect) &gt; 0 AND timestamp &lt; ( &quot;.time().&quot; -($subselect) * 24 * 3600)&quot;;</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Fast_portable_SQL&diff=7778 2008-01-14T05:10:13Z

<p>Martinlanghoff: </p> <hr /> <div>This is a work in progress! We keep notes here of bits of SQL that we know that<br /> <br /> * Work on all supported DBs (this is tricky!)<br /> * Are scalable and fast<br /> <br /> A key strategy for scalability is to ensure we do as much work as possible in the DB with minimal back-and-forth with PHP. Modern DB engines have very smart optimizers and if we play to their strenghts, can process millions of records in milliseconds. To hit those strenghts we want to reduce chattiness with the DB -- one &quot;smart&quot; SQL query (even if complex) is thousand of times better than a foreach loop in PHP that issues a thousand SQL queries. At least it will be more than a thousand times faster ;-)<br /> <br /> <br /> =UPDATE with JOINs=<br /> <br /> A good scalable way to update a lot of data is to combine the UPDATE with a SUBSELECT, to UPDATE the data directly from the DB itself. The rows never need to go back and forth to PHP, so this is extremely fast. The problem is that it is very hard to get it portable across DBs.<br /> <br /> Problems<br /> <br /> * Pg and MySQL disagree on the extended syntax of UPDATE with JOIN<br /> * MySQL does not support to have the table being updated in a subselect (but it supports it as JOINed table with a different alias - Pg does not support this)<br /> <br /> ==Portable examples==<br /> <br /> Fix a broken relation - this is roughly equivalent to a subselect with a LEFT OUTER JOIN:<br /> <br /> UPDATE {$CFG-&gt;prefix}course <br /> SET category = $defaultcategory<br /> WHERE<br /> NOT EXISTS (SELECT id FROM {$CFG-&gt;prefix}course_categories WHERE id={$CFG-&gt;prefix}course.category)<br /> AND mdl_course.id != $SITEID</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Developer_documentation&diff=567 2008-01-14T04:53:28Z

<p>Martinlanghoff: /* Guidelines */</p> <hr /> <div>&lt;p class=&quot;note&quot;&gt;'''Note:''' New developer documentation pages should be added to the ''Development namespace'' by typing &lt;code&gt;Development:&lt;/code&gt; before the new page name i.e. &lt;code&gt;&lt;nowiki&gt;[[New page name]]&lt;/nowiki&gt;&lt;/code&gt;.&lt;br /&gt;&lt;br /&gt;If you are a developer, you probably want to change your [[Special:Preferences|preferences]] to include the Development namespace in searches.&lt;br /&gt;&lt;br /&gt;A page may be added to the Developer category by typing &lt;code&gt;&lt;nowiki&gt;[[Category:New page name]]&lt;/nowiki&gt;&lt;/code&gt; at the bottom of the page.&lt;/p&gt;<br /> <br /> ==How Moodle development works==<br /> <br /> This [[Overview|overview of the Moodle development process]] may be handy in understanding how the development of Moodle occurs and how people become Moodle developers.<br /> <br /> ==Guidelines==<br /> <br /> The following guidelines are crucial reading for anyone wanting to contribute to the Moodle code base:<br /> *[[Coding|Coding guidelines]] have to be followed by all Moodle developers<br /> *[[Moodle design goals]] spells out the basic design goals behind Moodle<br /> *[[Interface guidelines]] aim to provide a common feel to the Moodle user interface<br /> *[[CVS (developer)|Moodle CVS for developers]] explains how to work with the Moodle code in CVS<br /> *[[Tracker]] explains the Moodle Tracker for keeping track of bugs, issues, feature requests etc<br /> *[[Working with the Community|Working with the Community]] explains how to engage with the dev community and discuss changes<br /> *[[Unit tests|Unit tests]] explains how to run the unit tests, and how to write new test cases.<br /> *[[Fast portable SQL]] shows SQL techniques that are fast, efficient, and known to work on all supported DBs.<br /> <br /> ==Documentation for core components==<br /> <br /> This section is for documentation of specific components of the existing core Moodle code. Discussion of components that are under discussion or in development can be found in the [[Developer notes]] or on the [[Roadmap]].<br /> <br /> The documents below give a general overview. For detailed function-by-function documentation, see the [http://phpdocs.moodle.org/ phpDocumentor] documentation that is automatically generated from the comments in the code. And don't forget that the most up-to-date and detailed description of how the code works is the code itself, and you can [http://xref.moodle.org/nav.html?index.html browse the code online using phpXRef]. Moodle code should be easy to read and understand. Use the source, Luke!<br /> <br /> ===Core components that affect everything===<br /> <br /> *[[Database schema introduction|The database schema]]<br /> *lib/moodlelib.php <br /> *[[lib/weblib.php|lib/weblib.php]] for outputting stuff.<br /> *[[XMLDB_Documentation|Database abstraction layer]] @ v[[1.7]]<br /> *[[Roles|Roles and Capabilities system]] @ v[[1.7]] for controlling who can do what.<br /> *[[lib/formslib.php|Forms library]] @ v[[1.8]] for creating accessible and secure HTML forms that let users edit things.<br /> <br /> ===Core libraries with a more specific uses===<br /> <br /> *[[Authentication API]]<br /> *[[Cookieless Sessions]]<br /> *[[Email processing]]<br /> *[[Environment checking|Environment checking]] before install, check the user's server to ensure Moodle will work there.<br /> *[[Groups|Groups system]]<br /> *[[Grades|Gradebook]]<br /> *[[Moodle Network|Moodle Network]]<br /> *[[Question engine]]<br /> *[[Stats package]]<br /> *[[UTF-8 migration|Migration to UTF-8]] @ v[[:Category:Moodle 1.6|1.6]]<br /> *[http://developer.yahoo.com/yui YUI JavaScript library] - YUI was selected as the official AJAX library for Moodle.<br /> *[[lib/graphlib|lib/graphlib]]<br /> <br /> ===Modules included in the standard distribution===<br /> <br /> *[[Quiz developer docs|Quiz module]]<br /> *[[SCORM schema|SCORM module 1.5 schema]]<br /> <br /> ==How you can contribute==<br /> <br /> ===Make a new plugin===<br /> <br /> The M in Moodle stands for modular, and the easiest, most maintainable way to add new functionality to Moodle is by using one of the many plugin APIs. There are many types of plugin you can write:<br /> *[[Modules|Activity modules]]<br /> *[[Admin reports|Admin reports]]<br /> *[[Assignment types|Assignment types]]<br /> *[[Authentication plugins|Authentication plugins]]<br /> *[[Blocks|Blocks]]<br /> *[[Course formats]]<br /> *[[Course Report Plugins|Course reports]]<br /> *[[Database fields|Database fields]]<br /> *[[Database presets|Database presets]]<br /> *[[Enrolment plugins|Enrolment plugins]]<br /> *[[Filters|Filters]]<br /> *[[Gradebook plugins|Gradebook plugins]]<br /> **[[Gradebook report|Gradebook report]]<br /> **[[Gradebook export|Gradebook export]]<br /> **[[Gradebook import|Gradebook import]]<br /> *[[Question engine|Question engine]]<br /> *[[Question import/export formats|Question import/export formats]]<br /> *[[How to write a quiz report plugin|Quiz reports]]<br /> *[[Resource types|Resource types]]<br /> *[[SSO plugins|SSO plugins]]<br /> *[[Search engine adapters|Search engine adapters]]<br /> <br /> <br /> <br /> When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 Moodle modules and plugins database].<br /> <br /> ===Change core code===<br /> <br /> Some types of change can only be made by editing the core Moodle code. Such changes are much harder to maintain than plugins. If you want your core change to be considered for inclusion in the official Moodle release, you need to create an issue in the [[Tracker|tracker]], and attach your change as a [[How_to_create_a_patch|patch]]. It is also a good idea to discuss your ideas in the forums first.<br /> <br /> ===Ways to contribute that do not involve PHP programming===<br /> <br /> *[[Themes|Create Moodle themes]]<br /> *[[Translation|Translate Moodle into other languages]]<br /> *[[MoodleDocs:Guidelines for contributors|Help document Moodle]]<br /> *[[Database schemas|Database schemas]]<br /> *[[Tests|Join the testing effort]], which involves [[Tracker|participating in the bug tracker]]<br /> <br /> ==Plans for the future==<br /> <br /> Ideas for and details of planned future features of Moodle are initially discussed on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course at moodle.org. That developer discussions are intermixed with user discussions in the same forums may seem strange at first but is one of the reasons for the success of Moodle. It is important that both end-users and developers discuss the future features together.<br /> <br /> Once ideas begin to crystallize on the forums they can be summarized in this wiki, either as part of the [[Roadmap]] or in the form of [[Developer notes]]. These pages then form the basis for further discussion in the forums.<br /> <br /> *[[Roadmap]]<br /> *[[Developer notes|Developer notes]]<br /> *[[Student projects]]<br /> *[[Developer conferences]]<br /> <br /> == Resources and tools ==<br /> <br /> *[[Developer FAQ]] - frequently asked questions, especially useful for newcomers to Moodle<br /> *[[Finding_your_way_into_the_Moodle_code|Finding your way into the Moodle code]] - also aimed at newcomers<br /> *[http://tracker.moodle.org/ Moodle tracker] - bug reports, feature requests and other tracked issues<br /> **[[Firefox tracker search]] - How to setup a firefox quicksearch to easily navigate to moodle bugs<br /> *[[Unmerged files]] - changes on the stable branch in CVS that have not been merged to HEAD<br /> *Browse the code online:<br /> **[http://cvs.moodle.org/moodle/ the code with a complete change history from CVS]<br /> **[http://xref.moodle.org/index.html the code, with links generated by PHPXref]<br /> *[http://phpdocs.moodle.org/ Moodle PHP doc reference] - compiled from the comment attached to each class and function in the code<br /> *[[Database Schema|Database Schema]] - for recent releases<br /> *[http://moodle.org/course/view.php?id=5#4 Development news and discussion] section of Using Moodle course<br /> **especially the [http://moodle.org/mod/forum/view.php?id=55 General developer forum]<br /> **[[Filters used on the Moodle.org forums|cool tricks you can use in the moodle.org forums]]<br /> *Some tools people use when working on Moodle code:<br /> **[[Setting_up_Eclipse|Setting up Eclipse for Moodle development]] - Eclipse is a great editor to use for php development, if you can work out how to set it up.<br /> **[[vim|Setting up Vim for Moodle development]]<br /> **[[ctags|Ctags]] - Using a tags file to navigate code<br /> **[[W3C_validation|W3C HTML validator]] - Moodle has built in support to make using it easier.<br /> **Firebug plugin for Firefox.<br /> <br /> ==See also==<br /> <br /> *[http://security.moodle.org/ Moodle Security Centre]<br /> *[http://moodle.com/partners/ Moodle Partners] - providers of custom Moodle development services<br /> <br /> <br /> [[es:Documentación para Desarrolladores]]<br /> [[fr:Documentation développeur]]<br /> [[pt:Desenvolvimento:Documentação para programadores]]<br /> [[zh:开发者文档]]<br /> [[ja:開発者ドキュメント]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Latest_release_notes&diff=25255 2007-12-27T22:34:36Z

<p>Martinlanghoff: /* Headline features */</p> <hr /> <div>{{About Moodle}}<br /> <br /> ==Moodle 1.9 Beta==<br /> <br /> Released: 14th August 2007<br /> <br /> This is a DEVELOPMENT RELEASE made available for wider testing by the community in preparation for a polished release of 1.9 in the coming weeks. It should not be used for production sites unless you are prepared to report the bugs you find in the [http://tracker.moodle.org Moodle Tracker], hopefully with your patches attached. :-)<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10190 the full list of fixed issues in 1.9 so far].<br /> <br /> ===Headline features===<br /> <br /> * [[Development:Grades|Gradebook]] - Moodle.com (funded by Open University)<br /> :: Completely rewritten from scratch for speed and flexibility. The new gradebook consists of plugins for reports, imports and exports. There are a number of standard reports which are useful for graders, students etc. The grader report allows you to treat the gradebook much more like a spreadsheet with manual editing, calculations, aggregations, weighting, locking, hiding, textual notes and so on.<br /> * [[Development:Outcomes|Outcomes]] - Moodle.com<br /> :: You can also now develop a list of expected outcomes (competencies) and connect these to courses and activities. You can even grade against multiple outcomes at once (ie Rubrics).<br /> * [[Development:Events|Events API]] - Moodle.com<br /> ::The new Events API provides a way for any code to &quot;hook&quot; into events in a clean, loosely coupled way. It's the foundation of the new gradebook. A lot of events in Moodle (such as adding a user or a course) now trigger events that developers can hook into.<br /> * [[Development:Scalability|Scalability and performance improvements]] improvements - Catalyst IT Ltd<br /> ::A complete overhaul of the [[Roles]] implementation for correctness and scalability. Large sites with thousands of courses and users now load quickly and behave well under heavy traffic, thanks to reworked code for Roles. Additional boost for sites using PHP precompilers and significant improvements in the DB access code in all databases.<br /> * [[MNet Mahara|Moodle Network - Mahara Interoperability]] - Catalyst IT Ltd<br /> ::Moodle v1.9 and [http://www.mahara.org/ Mahara E-porfolio v0.9] now do transparent Single Sign On - one to one, one to many, many to many. Students can maintain their personal [[E-portfolio|E-portfolios]] in Mahara.<br /> * [[Tags]] - Luiz Cruz ([[Student_projects/Social_Networking_features|GSOC Social Networking project]])<br /> :: Allows users to describe their own interests in terms of tags, which creates interest pages around those tags, bringing information together from a variety of sources.<br /> * [[Question_Engine_Changes_in_Moodle_1.9|Improved question bank]] - Jamie Pratt funded by [http://www.fun.ac.jp/en/ Future University Hakodate].<br /> ::Allows questions to be shared by the whole site, a course category, a single course, or be kept private to a single module. More control over who can do what to each question. Improved file management for files linked to by questions.<br /> * [[Notes]] - Andrei Bautu ([[Student projects/User Management Improvements|GSOC User Management Improvements project]])<br /> :: Detailed notes can be kept about individual users (for example teachers might want to keep and share notes about students in their class).<br /> * [[Bulk user actions]] - Andrei Bautu ([[Student projects/User Management Improvements|GSOC User Management Improvements project]])<br /> ::Administrators can perform bulk user actions, such as the mass deletion of user accounts. Extended features in the bulk user upload script to allow generation of user fields based on templates. <br /> * New Custom Corners theme - Urs Hunkler<br /> :: Beautiful and curvy (in all browsers).<br /> <br /> ===Other major improvements===<br /> <br /> * [[Groups]] and [[Groupings]] - UPLGC, Catalyst Ltd, Moodle.com<br /> :: New support for groupings (groups of groups) which was added briefly and then removed from 1.8.x. Activities and resources may be assigned to particular groupings.<br /> * [[NTLM authentication|Active Directory NTLM Single Sign On]] - Catalyst Ltd<br /> :: Integrated a reworked version of the NTLM Single Sign On, originally by Dan Marsden.<br /> * New theme settings<br /> ** Category themes - can now set the theme for a category which will apply to all sub-categories and courses<br /> ** Theme order - new setting ''$CFG-&gt;themeorder'' which sets the priority of the themes from highest to lowest.<br /> * Ability to control block visibility with roles<br /> ** A new [[Capabilities/moodle/block:view|moodle/block:view]] capability has been added which allows control of who can view blocks from the roles system. This allows certain blocks to be hidden from the guest user, for example. See [[Block_permissions|Hiding blocks from certain users]].<br /> * Oracle Support - Catalyst Ltd, USQ<br /> :: Significant enhancements in Oracle support, scalability and performance<br /> <br /> ===Module improvements===<br /> <br /> * Quiz/Question improvements:<br /> ** Improved question bank, as above.<br /> ** Quizzes now listed on the MyMoodle page. (Implemented by Stephen Bourget and Tim Hunt.)<br /> ** A quiz can now [[Quiz submission email notification|send emails when an attempt is finished]] - a confirmation to the student, a notification to all teachers, or both. (Implemented by Graham Miller of [http://www.webenhanced.com.au/ Web Enhanced Solutions] and Tim Hunt.)<br /> ** Third party question types can now implement Moodle XML and other import and export format. (Implemented by Howard Miller.)<br /> ** Gift Import/Export format can now handle Essay and Description question types.<br /> ** Some slight improvements to quiz layout. See [http://tracker.moodle.org/browse/MDL-10374 MDL-10374] for details. Theme designers please note.<br /> ** Multiple choice questions now show the feedback for all the options to students on the review page after the attempt is over.<br /> <br /> ''Developers please add news here!''<br /> <br /> ===Notes===<br /> <br /> * In the new accesslib there is a subtle difference in how we resolve conflicts between 'allow' and 'prevent' capabilities. See [[Development:Roles#Capability-locality_changes_in_v1.9|Capability-locality changes in 1.9]].<br /> <br /> ==Moodle 1.8.3==<br /> <br /> Released: 11th October 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10230&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.3].<br /> <br /> ===Highlights===<br /> * Some crucial performance fixes<br /> * Many little annoying bugs squashed<br /> <br /> <br /> <br /> ==Moodle 1.8.2==<br /> <br /> Released: 8th July 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10220&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.2].<br /> <br /> ===Highlights===<br /> * Two XSS security vulnerabilities (one reported in the wild) were fixed.<br /> <br /> ==Moodle 1.8.1==<br /> <br /> Released: 14th June 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10213&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.1].<br /> <br /> ===Highlights===<br /> * The groups implementation has been cleaned up somewhat from the 1.8 release. The '''groupings''' GUI that appeared in 1.8 has been removed, because groupings are not complete and should not be used yet. Moodle 1.8 sites that have created groupings should upgrade to 1.8.1 to have groupings reset ... otherwise there could be problem when upgrading to the real groupings in 1.9 or later.<br /> <br /> ==Moodle 1.8==<br /> <br /> Released: 31st March 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10130 the full list of fixed issues in 1.8].<br /> <br /> ===Headline features===<br /> <br /> * [[Accessibility]] - Moodle.com <br /> :: The Moodle interface is now compliant with XHTML Strict 1.0 and major accessibility standards.<br /> * [[Moodle Network]] - Catalyst, Richard Wyles<br /> :: We can now set up peer Moodle installations allowing users to roam from one site to another, using comprehensive SSO and transparent remote enrolments. Administrators at the originating Moodle install can see logs of remote activity. You can also run your Moodle in &quot;Hub&quot; mode where any Moodle install can connect and users roam across.<br /> * [[Web Services API]] - Catalyst, Richard Wyles<br /> :: The Moodle Network code includes an XML-RPC call dispatcher that can expose the WHOLE Moodle API to trusted hosts. We will building on this in further versions but you can start using it now if you need to.<br /> * [[Development:lib/formslib.php|Moodle forms library]] - Moodle.com <br /> :: Majority of forms now use a single API for defining forms consistently and collecting data safely without using any HTML at all.<br /> * [[Multi Authentication]] - Iñaki Arenaza / Catalyst / Moodle.com<br /> :: It is now easier to configure multiple sources of authentication at once. WARNING: the format for authentication plugins has changed, so custom plugins may be broken, however it's very easy to convert old code to the new format. More details can be found in /auth/README.txt.<br /> * [[Development:Customisable user profiles|Customisable User Profiles]] - Pukunui Technology<br /> ::Allow new arbitrary fields to be added to the user profile, with more control over what fields appear on what signup and profile editing screens.<br /> * Groups refactor - OU / Moodle.com<br /> ::Groups code has been reorganised to make it more flexible for the future (see 1.9). <br /> * [http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&amp;requestId=10221 Roles improvements] - Moodle.com<br /> :: In addition to many Roles fixes and refinements, Moodle 1.8 has separated the SYSTEM context from the SITE context (which makes it more like 1.6 used to work). The SITE context is the &quot;front page course&quot; and its activities. This should make it easier for admins to set up permissions. Login as and switching of roles was rewritten. Administrators can view recommended permission settings of legacy roles and may reset legacy roles to defaults.<br /> * [http://tracker.moodle.org/browse/MDL-7993 Support for ODS export] - Moodle.com<br /> ::Open Document Format should solve majority of current problems with exports into proprietary Excel format. You may need to install special import plugin if you are using MS Office.<br /> <br /> ===Known problems===<br /> * CAS auth not working<br /> <br /> ===Module improvements===<br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :: Payment managers can obtain an authorization code over phone from customer's bank if the credit card of the user cannot be captured on the internet directly.<br /> <br /> ''Developers please add news here!''<br /> <br /> ===See also===<br /> *[[Upgrading to Moodle 1.8]]<br /> <br /> ==Moodle 1.7.3==<br /> <br /> 11th October, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10212&amp;styleName=Html&amp;projectId=10011 This page shows issues resolved in this version]<br /> <br /> <br /> ==Moodle 1.7.2==<br /> <br /> 30th March, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10174 This page shows issues resolved in this version]<br /> <br /> ===Security===<br /> <br /> * Unintended logouts are now prevented - sesskey added to logout.php script<br /> * Fixed problem with visible posts in user profile when &quot;forceloginforprofiles&quot; disabled<br /> * Fixed visibility of site blog entries<br /> * Corrected wrong includes in lams<br /> * XSS injection in SCORM 1.2 reports<br /> * Fixed old problem with approvals in Data module, edited entries were approved automatically<br /> * Fixed escaping in shell commands (Win32 platform only)<br /> * Fixed visibility of blog drafts<br /> * Rewritten parameter handling in repository plugin<br /> * Fixed XSS in login block<br /> <br /> ==Moodle 1.7.1==<br /> <br /> 17th January, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10151 This page shows details about issues resolved in this version]<br /> <br /> ==Moodle 1.7==<br /> <br /> 7th November, 2006<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10120&amp;styleName=Html&amp;projectId=10011&amp;Create=Create This page shows details about issues resolved in this version] <br /> <br /> ===Headline features=== <br /> <br /> * [[Roles]] <br /> :: Permissions based on fine-grained capabilities allow all kinds of roles to be created and assigned in all contexts around Moodle. This creates a great deal more flexibility in the permissions that you can grant to people. <br /> * [[Development:XMLDB Documentation|XML Database Schema]] <br /> :: added support for MS-SQL and Oracle with more databases to come. Developers now have just one XML file to edit when changing the database structure, and there is even a very funky editor for this file built-in to Moodle <br /> * New Admin interface <br /> :: Completely new admin interface, with accessible design and cool features to make access to settings fast and easy. <br /> * [[Unit tests|Unit testing framework]] <br /> :: Making it easier for developers to write test code, which should ultimately lead to a more reliable Moodle. <br /> * [[AJAX]] Course editing (STILL UNSTABLE IN 1.7 RELEASE AND OFF BY DEFAULT, USE WITH CAUTION!) <br /> :: The Topics and Weekly course formats now feature AJAX editing which means you can drag drop blocks, activities and sections (weeks/topics) and it all happens instantly. No more page reloading!<br /> <br /> ===Module improvements=== <br /> <br /> * Improvements to the [[Assignment module]] <br /> **New type Advanced uploading of files <br /> <br /> * Improvements to the [[Database module]] <br /> **Template/Field settings can now be saved as Presets and shared across a site. <br /> **Presets are just zip files, and can also be shared between sites. <br /> **Moodle 1.7 comes with one sample preset (an Image Gallery) with more to come. <br /> **New latitude/longitude data type <br /> <br /> * Improvements to the [[Lesson module]] <br /> **Now has a more unified view of lesson screens. <br /> **Teacher editing: <br /> ***Collapsed view has a nicer format, displays more information regarding each page and allows the creation of new pages. <br /> ***Editing is now speedier by replacing 3 second redirect delays with a notification system. <br /> **New feature: display default feedback. <br /> ***Default is '''On''' so previous lessons behave as before. <br /> ***Description: if no ''response'' is entered for a question answer and this setting is turned '''Off''', then the user skips the feedback page. <br /> **Graceful degrade of JavaScript. <br /> **Several bug fixes. <br /> <br /> * Improvements to the [[Quiz module]] <br /> :* The teacher can configure comments that are displayed to the student at the end of their attempt, with the comment displayed depending on the student's score. <br /> <br /> * Improvements to some core question types <br /> :* All question types can now have some general feedback. This is displayed to all students after they have finished the question (depending on the quiz settings) and does not depend on what response the student gave. Use this to tell the student what the question was about, or link them to more information about the topic it covers. <br /> :* [[Matching question type|Matching]] questions can have extra wrong answers, and work when two questions have the same answer. <br /> :* [[Multiple Choice question type|Multiple Choice]] questions can have feedback for the whole question, as well as specific answers. This is particularly useful for multiple-response questions. <br /> :* [[Numerical question type|Numerical]] questions can have different answers with different precisions and scores. (Previously this was only supported via GIFT import. Now you can edit questions like this.) <br /> <br /> * Improvements to the [[Wiki module]] <br /> :* While editing a wiki page it is now locked so that others cannot try to change it at the same time. Teachers can override the lock. <br /> :* Minor bugfixes (mostly to fix problems that occured when using Postgres database). <br /> <br /> ===Enrolment plugin improvements=== <br /> <br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :*Accepts 'Electronic Checks (ACH)'. After a user approving echeck, an admin who has upload csv capacity must import a CSV file to get the user enrolled in the Payment Management page. <br /> :*Autoconfigures credit card and echeck types if the merchant does not accept some types of them.<br /> <br /> == See also ==<br /> *[[Old releases|Old release notes]]<br /> <br /> [[es:Notas de versiones]]<br /> [[fr:Notes de mise à jour]]<br /> [[pt:Versões do Moodle]]<br /> [[ru:Примечания к версиям]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Latest_release_notes&diff=25254 2007-12-27T21:43:50Z

<p>Martinlanghoff: /* Other major improvements */</p> <hr /> <div>{{About Moodle}}<br /> <br /> ==Moodle 1.9 Beta==<br /> <br /> Released: 14th August 2007<br /> <br /> This is a DEVELOPMENT RELEASE made available for wider testing by the community in preparation for a polished release of 1.9 in the coming weeks. It should not be used for production sites unless you are prepared to report the bugs you find in the [http://tracker.moodle.org Moodle Tracker], hopefully with your patches attached. :-)<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10190 the full list of fixed issues in 1.9 so far].<br /> <br /> ===Headline features===<br /> <br /> * [[Development:Grades|Gradebook]] - Moodle.com (funded by Open University)<br /> :: Completely rewritten from scratch for speed and flexibility. The new gradebook consists of plugins for reports, imports and exports. There are a number of standard reports which are useful for graders, students etc. The grader report allows you to treat the gradebook much more like a spreadsheet with manual editing, calculations, aggregations, weighting, locking, hiding, textual notes and so on.<br /> * [[Development:Outcomes|Outcomes]] - Moodle.com<br /> :: You can also now develop a list of expected outcomes (competencies) and connect these to courses and activities. You can even grade against multiple outcomes at once (ie Rubrics).<br /> * [[Development:Events|Events API]] - Moodle.com<br /> ::The new Events API provides a way for any code to &quot;hook&quot; into events in a clean, loosely coupled way. It's the foundation of the new gradebook. A lot of events in Moodle (such as adding a user or a course) now trigger events that developers can hook into.<br /> * [[Development:Scalability|Scalability and performance improvements]] improvements - Catalyst Ltd<br /> ::A complete overhaul of the [[Roles]] implementation for correctness and scalability. Large sites with thousands of courses and users now load quickly and behave well under heavy traffic, thanks to reworked code for Roles. Additional boost for sites using PHP precompilers and significant improvements in the DB access code in all databases.<br /> * [[Tags]] - Luiz Cruz ([[Student_projects/Social_Networking_features|GSOC Social Networking project]])<br /> :: Allows users to describe their own interests in terms of tags, which creates interest pages around those tags, bringing information together from a variety of sources.<br /> * [[Question_Engine_Changes_in_Moodle_1.9|Improved question bank]] - Jamie Pratt funded by [http://www.fun.ac.jp/en/ Future University Hakodate].<br /> ::Allows questions to be shared by the whole site, a course category, a single course, or be kept private to a single module. More control over who can do what to each question. Improved file management for files linked to by questions.<br /> * [[Notes]] - Andrei Bautu ([[Student projects/User Management Improvements|GSOC User Management Improvements project]])<br /> :: Detailed notes can be kept about individual users (for example teachers might want to keep and share notes about students in their class).<br /> * [[Bulk user actions]] - Andrei Bautu ([[Student projects/User Management Improvements|GSOC User Management Improvements project]])<br /> ::Administrators can perform bulk user actions, such as the mass deletion of user accounts. Extended features in the bulk user upload script to allow generation of user fields based on templates. <br /> * New Custom Corners theme - Urs Hunkler<br /> :: Beautiful and curvy (in all browsers).<br /> <br /> ===Other major improvements===<br /> <br /> * [[Groups]] and [[Groupings]] - UPLGC, Catalyst Ltd, Moodle.com<br /> :: New support for groupings (groups of groups) which was added briefly and then removed from 1.8.x. Activities and resources may be assigned to particular groupings.<br /> * [[NTLM authentication|Active Directory NTLM Single Sign On]] - Catalyst Ltd<br /> :: Integrated a reworked version of the NTLM Single Sign On, originally by Dan Marsden.<br /> * New theme settings<br /> ** Category themes - can now set the theme for a category which will apply to all sub-categories and courses<br /> ** Theme order - new setting ''$CFG-&gt;themeorder'' which sets the priority of the themes from highest to lowest.<br /> * Ability to control block visibility with roles<br /> ** A new [[Capabilities/moodle/block:view|moodle/block:view]] capability has been added which allows control of who can view blocks from the roles system. This allows certain blocks to be hidden from the guest user, for example. See [[Block_permissions|Hiding blocks from certain users]].<br /> * Oracle Support - Catalyst Ltd, USQ<br /> :: Significant enhancements in Oracle support, scalability and performance<br /> <br /> ===Module improvements===<br /> <br /> * Quiz/Question improvements:<br /> ** Improved question bank, as above.<br /> ** Quizzes now listed on the MyMoodle page. (Implemented by Stephen Bourget and Tim Hunt.)<br /> ** A quiz can now [[Quiz submission email notification|send emails when an attempt is finished]] - a confirmation to the student, a notification to all teachers, or both. (Implemented by Graham Miller of [http://www.webenhanced.com.au/ Web Enhanced Solutions] and Tim Hunt.)<br /> ** Third party question types can now implement Moodle XML and other import and export format. (Implemented by Howard Miller.)<br /> ** Gift Import/Export format can now handle Essay and Description question types.<br /> ** Some slight improvements to quiz layout. See [http://tracker.moodle.org/browse/MDL-10374 MDL-10374] for details. Theme designers please note.<br /> ** Multiple choice questions now show the feedback for all the options to students on the review page after the attempt is over.<br /> <br /> ''Developers please add news here!''<br /> <br /> ===Notes===<br /> <br /> * In the new accesslib there is a subtle difference in how we resolve conflicts between 'allow' and 'prevent' capabilities. See [[Development:Roles#Capability-locality_changes_in_v1.9|Capability-locality changes in 1.9]].<br /> <br /> ==Moodle 1.8.3==<br /> <br /> Released: 11th October 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10230&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.3].<br /> <br /> ===Highlights===<br /> * Some crucial performance fixes<br /> * Many little annoying bugs squashed<br /> <br /> <br /> <br /> ==Moodle 1.8.2==<br /> <br /> Released: 8th July 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10220&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.2].<br /> <br /> ===Highlights===<br /> * Two XSS security vulnerabilities (one reported in the wild) were fixed.<br /> <br /> ==Moodle 1.8.1==<br /> <br /> Released: 14th June 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10213&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.1].<br /> <br /> ===Highlights===<br /> * The groups implementation has been cleaned up somewhat from the 1.8 release. The '''groupings''' GUI that appeared in 1.8 has been removed, because groupings are not complete and should not be used yet. Moodle 1.8 sites that have created groupings should upgrade to 1.8.1 to have groupings reset ... otherwise there could be problem when upgrading to the real groupings in 1.9 or later.<br /> <br /> ==Moodle 1.8==<br /> <br /> Released: 31st March 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10130 the full list of fixed issues in 1.8].<br /> <br /> ===Headline features===<br /> <br /> * [[Accessibility]] - Moodle.com <br /> :: The Moodle interface is now compliant with XHTML Strict 1.0 and major accessibility standards.<br /> * [[Moodle Network]] - Catalyst, Richard Wyles<br /> :: We can now set up peer Moodle installations allowing users to roam from one site to another, using comprehensive SSO and transparent remote enrolments. Administrators at the originating Moodle install can see logs of remote activity. You can also run your Moodle in &quot;Hub&quot; mode where any Moodle install can connect and users roam across.<br /> * [[Web Services API]] - Catalyst, Richard Wyles<br /> :: The Moodle Network code includes an XML-RPC call dispatcher that can expose the WHOLE Moodle API to trusted hosts. We will building on this in further versions but you can start using it now if you need to.<br /> * [[Development:lib/formslib.php|Moodle forms library]] - Moodle.com <br /> :: Majority of forms now use a single API for defining forms consistently and collecting data safely without using any HTML at all.<br /> * [[Multi Authentication]] - Iñaki Arenaza / Catalyst / Moodle.com<br /> :: It is now easier to configure multiple sources of authentication at once. WARNING: the format for authentication plugins has changed, so custom plugins may be broken, however it's very easy to convert old code to the new format. More details can be found in /auth/README.txt.<br /> * [[Development:Customisable user profiles|Customisable User Profiles]] - Pukunui Technology<br /> ::Allow new arbitrary fields to be added to the user profile, with more control over what fields appear on what signup and profile editing screens.<br /> * Groups refactor - OU / Moodle.com<br /> ::Groups code has been reorganised to make it more flexible for the future (see 1.9). <br /> * [http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&amp;requestId=10221 Roles improvements] - Moodle.com<br /> :: In addition to many Roles fixes and refinements, Moodle 1.8 has separated the SYSTEM context from the SITE context (which makes it more like 1.6 used to work). The SITE context is the &quot;front page course&quot; and its activities. This should make it easier for admins to set up permissions. Login as and switching of roles was rewritten. Administrators can view recommended permission settings of legacy roles and may reset legacy roles to defaults.<br /> * [http://tracker.moodle.org/browse/MDL-7993 Support for ODS export] - Moodle.com<br /> ::Open Document Format should solve majority of current problems with exports into proprietary Excel format. You may need to install special import plugin if you are using MS Office.<br /> <br /> ===Known problems===<br /> * CAS auth not working<br /> <br /> ===Module improvements===<br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :: Payment managers can obtain an authorization code over phone from customer's bank if the credit card of the user cannot be captured on the internet directly.<br /> <br /> ''Developers please add news here!''<br /> <br /> ===See also===<br /> *[[Upgrading to Moodle 1.8]]<br /> <br /> ==Moodle 1.7.3==<br /> <br /> 11th October, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10212&amp;styleName=Html&amp;projectId=10011 This page shows issues resolved in this version]<br /> <br /> <br /> ==Moodle 1.7.2==<br /> <br /> 30th March, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10174 This page shows issues resolved in this version]<br /> <br /> ===Security===<br /> <br /> * Unintended logouts are now prevented - sesskey added to logout.php script<br /> * Fixed problem with visible posts in user profile when &quot;forceloginforprofiles&quot; disabled<br /> * Fixed visibility of site blog entries<br /> * Corrected wrong includes in lams<br /> * XSS injection in SCORM 1.2 reports<br /> * Fixed old problem with approvals in Data module, edited entries were approved automatically<br /> * Fixed escaping in shell commands (Win32 platform only)<br /> * Fixed visibility of blog drafts<br /> * Rewritten parameter handling in repository plugin<br /> * Fixed XSS in login block<br /> <br /> ==Moodle 1.7.1==<br /> <br /> 17th January, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10151 This page shows details about issues resolved in this version]<br /> <br /> ==Moodle 1.7==<br /> <br /> 7th November, 2006<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10120&amp;styleName=Html&amp;projectId=10011&amp;Create=Create This page shows details about issues resolved in this version] <br /> <br /> ===Headline features=== <br /> <br /> * [[Roles]] <br /> :: Permissions based on fine-grained capabilities allow all kinds of roles to be created and assigned in all contexts around Moodle. This creates a great deal more flexibility in the permissions that you can grant to people. <br /> * [[Development:XMLDB Documentation|XML Database Schema]] <br /> :: added support for MS-SQL and Oracle with more databases to come. Developers now have just one XML file to edit when changing the database structure, and there is even a very funky editor for this file built-in to Moodle <br /> * New Admin interface <br /> :: Completely new admin interface, with accessible design and cool features to make access to settings fast and easy. <br /> * [[Unit tests|Unit testing framework]] <br /> :: Making it easier for developers to write test code, which should ultimately lead to a more reliable Moodle. <br /> * [[AJAX]] Course editing (STILL UNSTABLE IN 1.7 RELEASE AND OFF BY DEFAULT, USE WITH CAUTION!) <br /> :: The Topics and Weekly course formats now feature AJAX editing which means you can drag drop blocks, activities and sections (weeks/topics) and it all happens instantly. No more page reloading!<br /> <br /> ===Module improvements=== <br /> <br /> * Improvements to the [[Assignment module]] <br /> **New type Advanced uploading of files <br /> <br /> * Improvements to the [[Database module]] <br /> **Template/Field settings can now be saved as Presets and shared across a site. <br /> **Presets are just zip files, and can also be shared between sites. <br /> **Moodle 1.7 comes with one sample preset (an Image Gallery) with more to come. <br /> **New latitude/longitude data type <br /> <br /> * Improvements to the [[Lesson module]] <br /> **Now has a more unified view of lesson screens. <br /> **Teacher editing: <br /> ***Collapsed view has a nicer format, displays more information regarding each page and allows the creation of new pages. <br /> ***Editing is now speedier by replacing 3 second redirect delays with a notification system. <br /> **New feature: display default feedback. <br /> ***Default is '''On''' so previous lessons behave as before. <br /> ***Description: if no ''response'' is entered for a question answer and this setting is turned '''Off''', then the user skips the feedback page. <br /> **Graceful degrade of JavaScript. <br /> **Several bug fixes. <br /> <br /> * Improvements to the [[Quiz module]] <br /> :* The teacher can configure comments that are displayed to the student at the end of their attempt, with the comment displayed depending on the student's score. <br /> <br /> * Improvements to some core question types <br /> :* All question types can now have some general feedback. This is displayed to all students after they have finished the question (depending on the quiz settings) and does not depend on what response the student gave. Use this to tell the student what the question was about, or link them to more information about the topic it covers. <br /> :* [[Matching question type|Matching]] questions can have extra wrong answers, and work when two questions have the same answer. <br /> :* [[Multiple Choice question type|Multiple Choice]] questions can have feedback for the whole question, as well as specific answers. This is particularly useful for multiple-response questions. <br /> :* [[Numerical question type|Numerical]] questions can have different answers with different precisions and scores. (Previously this was only supported via GIFT import. Now you can edit questions like this.) <br /> <br /> * Improvements to the [[Wiki module]] <br /> :* While editing a wiki page it is now locked so that others cannot try to change it at the same time. Teachers can override the lock. <br /> :* Minor bugfixes (mostly to fix problems that occured when using Postgres database). <br /> <br /> ===Enrolment plugin improvements=== <br /> <br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :*Accepts 'Electronic Checks (ACH)'. After a user approving echeck, an admin who has upload csv capacity must import a CSV file to get the user enrolled in the Payment Management page. <br /> :*Autoconfigures credit card and echeck types if the merchant does not accept some types of them.<br /> <br /> == See also ==<br /> *[[Old releases|Old release notes]]<br /> <br /> [[es:Notas de versiones]]<br /> [[fr:Notes de mise à jour]]<br /> [[pt:Versões do Moodle]]<br /> [[ru:Примечания к версиям]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Latest_release_notes&diff=25253 2007-12-27T21:42:35Z

<p>Martinlanghoff: /* Other major improvements */</p> <hr /> <div>{{About Moodle}}<br /> <br /> ==Moodle 1.9 Beta==<br /> <br /> Released: 14th August 2007<br /> <br /> This is a DEVELOPMENT RELEASE made available for wider testing by the community in preparation for a polished release of 1.9 in the coming weeks. It should not be used for production sites unless you are prepared to report the bugs you find in the [http://tracker.moodle.org Moodle Tracker], hopefully with your patches attached. :-)<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10190 the full list of fixed issues in 1.9 so far].<br /> <br /> ===Headline features===<br /> <br /> * [[Development:Grades|Gradebook]] - Moodle.com (funded by Open University)<br /> :: Completely rewritten from scratch for speed and flexibility. The new gradebook consists of plugins for reports, imports and exports. There are a number of standard reports which are useful for graders, students etc. The grader report allows you to treat the gradebook much more like a spreadsheet with manual editing, calculations, aggregations, weighting, locking, hiding, textual notes and so on.<br /> * [[Development:Outcomes|Outcomes]] - Moodle.com<br /> :: You can also now develop a list of expected outcomes (competencies) and connect these to courses and activities. You can even grade against multiple outcomes at once (ie Rubrics).<br /> * [[Development:Events|Events API]] - Moodle.com<br /> ::The new Events API provides a way for any code to &quot;hook&quot; into events in a clean, loosely coupled way. It's the foundation of the new gradebook. A lot of events in Moodle (such as adding a user or a course) now trigger events that developers can hook into.<br /> * [[Development:Scalability|Scalability and performance improvements]] improvements - Catalyst Ltd<br /> ::A complete overhaul of the [[Roles]] implementation for correctness and scalability. Large sites with thousands of courses and users now load quickly and behave well under heavy traffic, thanks to reworked code for Roles. Additional boost for sites using PHP precompilers and significant improvements in the DB access code in all databases.<br /> * [[Tags]] - Luiz Cruz ([[Student_projects/Social_Networking_features|GSOC Social Networking project]])<br /> :: Allows users to describe their own interests in terms of tags, which creates interest pages around those tags, bringing information together from a variety of sources.<br /> * [[Question_Engine_Changes_in_Moodle_1.9|Improved question bank]] - Jamie Pratt funded by [http://www.fun.ac.jp/en/ Future University Hakodate].<br /> ::Allows questions to be shared by the whole site, a course category, a single course, or be kept private to a single module. More control over who can do what to each question. Improved file management for files linked to by questions.<br /> * [[Notes]] - Andrei Bautu ([[Student projects/User Management Improvements|GSOC User Management Improvements project]])<br /> :: Detailed notes can be kept about individual users (for example teachers might want to keep and share notes about students in their class).<br /> * [[Bulk user actions]] - Andrei Bautu ([[Student projects/User Management Improvements|GSOC User Management Improvements project]])<br /> ::Administrators can perform bulk user actions, such as the mass deletion of user accounts. Extended features in the bulk user upload script to allow generation of user fields based on templates. <br /> * New Custom Corners theme - Urs Hunkler<br /> :: Beautiful and curvy (in all browsers).<br /> <br /> ===Other major improvements===<br /> <br /> * [[Groups]] and [[Groupings]] - UPLGC, Catalyst Ltd, Moodle.com<br /> :: New support for groupings (groups of groups) which was added briefly and then removed from 1.8.x. Activities and resources may be assigned to particular groupings.<br /> * [[NTLM authentication|NTLM Single Sign On]] - Catalyst Ltd<br /> :: Integrated a reworked version of the NTLM Single Sign On, originally by Dan Marsden<br /> * New theme settings<br /> ** Category themes - can now set the theme for a category which will apply to all sub-categories and courses<br /> ** Theme order - new setting ''$CFG-&gt;themeorder'' which sets the priority of the themes from highest to lowest.<br /> * Ability to control block visibility with roles<br /> ** A new [[Capabilities/moodle/block:view|moodle/block:view]] capability has been added which allows control of who can view blocks from the roles system. This allows certain blocks to be hidden from the guest user, for example. See [[Block_permissions|Hiding blocks from certain users]].<br /> * Oracle Support - Catalyst Ltd, USQ<br /> :: Significant enhancements in Oracle support, scalability and performance<br /> <br /> ===Module improvements===<br /> <br /> * Quiz/Question improvements:<br /> ** Improved question bank, as above.<br /> ** Quizzes now listed on the MyMoodle page. (Implemented by Stephen Bourget and Tim Hunt.)<br /> ** A quiz can now [[Quiz submission email notification|send emails when an attempt is finished]] - a confirmation to the student, a notification to all teachers, or both. (Implemented by Graham Miller of [http://www.webenhanced.com.au/ Web Enhanced Solutions] and Tim Hunt.)<br /> ** Third party question types can now implement Moodle XML and other import and export format. (Implemented by Howard Miller.)<br /> ** Gift Import/Export format can now handle Essay and Description question types.<br /> ** Some slight improvements to quiz layout. See [http://tracker.moodle.org/browse/MDL-10374 MDL-10374] for details. Theme designers please note.<br /> ** Multiple choice questions now show the feedback for all the options to students on the review page after the attempt is over.<br /> <br /> ''Developers please add news here!''<br /> <br /> ===Notes===<br /> <br /> * In the new accesslib there is a subtle difference in how we resolve conflicts between 'allow' and 'prevent' capabilities. See [[Development:Roles#Capability-locality_changes_in_v1.9|Capability-locality changes in 1.9]].<br /> <br /> ==Moodle 1.8.3==<br /> <br /> Released: 11th October 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10230&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.3].<br /> <br /> ===Highlights===<br /> * Some crucial performance fixes<br /> * Many little annoying bugs squashed<br /> <br /> <br /> <br /> ==Moodle 1.8.2==<br /> <br /> Released: 8th July 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10220&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.2].<br /> <br /> ===Highlights===<br /> * Two XSS security vulnerabilities (one reported in the wild) were fixed.<br /> <br /> ==Moodle 1.8.1==<br /> <br /> Released: 14th June 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10213&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.1].<br /> <br /> ===Highlights===<br /> * The groups implementation has been cleaned up somewhat from the 1.8 release. The '''groupings''' GUI that appeared in 1.8 has been removed, because groupings are not complete and should not be used yet. Moodle 1.8 sites that have created groupings should upgrade to 1.8.1 to have groupings reset ... otherwise there could be problem when upgrading to the real groupings in 1.9 or later.<br /> <br /> ==Moodle 1.8==<br /> <br /> Released: 31st March 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10130 the full list of fixed issues in 1.8].<br /> <br /> ===Headline features===<br /> <br /> * [[Accessibility]] - Moodle.com <br /> :: The Moodle interface is now compliant with XHTML Strict 1.0 and major accessibility standards.<br /> * [[Moodle Network]] - Catalyst, Richard Wyles<br /> :: We can now set up peer Moodle installations allowing users to roam from one site to another, using comprehensive SSO and transparent remote enrolments. Administrators at the originating Moodle install can see logs of remote activity. You can also run your Moodle in &quot;Hub&quot; mode where any Moodle install can connect and users roam across.<br /> * [[Web Services API]] - Catalyst, Richard Wyles<br /> :: The Moodle Network code includes an XML-RPC call dispatcher that can expose the WHOLE Moodle API to trusted hosts. We will building on this in further versions but you can start using it now if you need to.<br /> * [[Development:lib/formslib.php|Moodle forms library]] - Moodle.com <br /> :: Majority of forms now use a single API for defining forms consistently and collecting data safely without using any HTML at all.<br /> * [[Multi Authentication]] - Iñaki Arenaza / Catalyst / Moodle.com<br /> :: It is now easier to configure multiple sources of authentication at once. WARNING: the format for authentication plugins has changed, so custom plugins may be broken, however it's very easy to convert old code to the new format. More details can be found in /auth/README.txt.<br /> * [[Development:Customisable user profiles|Customisable User Profiles]] - Pukunui Technology<br /> ::Allow new arbitrary fields to be added to the user profile, with more control over what fields appear on what signup and profile editing screens.<br /> * Groups refactor - OU / Moodle.com<br /> ::Groups code has been reorganised to make it more flexible for the future (see 1.9). <br /> * [http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&amp;requestId=10221 Roles improvements] - Moodle.com<br /> :: In addition to many Roles fixes and refinements, Moodle 1.8 has separated the SYSTEM context from the SITE context (which makes it more like 1.6 used to work). The SITE context is the &quot;front page course&quot; and its activities. This should make it easier for admins to set up permissions. Login as and switching of roles was rewritten. Administrators can view recommended permission settings of legacy roles and may reset legacy roles to defaults.<br /> * [http://tracker.moodle.org/browse/MDL-7993 Support for ODS export] - Moodle.com<br /> ::Open Document Format should solve majority of current problems with exports into proprietary Excel format. You may need to install special import plugin if you are using MS Office.<br /> <br /> ===Known problems===<br /> * CAS auth not working<br /> <br /> ===Module improvements===<br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :: Payment managers can obtain an authorization code over phone from customer's bank if the credit card of the user cannot be captured on the internet directly.<br /> <br /> ''Developers please add news here!''<br /> <br /> ===See also===<br /> *[[Upgrading to Moodle 1.8]]<br /> <br /> ==Moodle 1.7.3==<br /> <br /> 11th October, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10212&amp;styleName=Html&amp;projectId=10011 This page shows issues resolved in this version]<br /> <br /> <br /> ==Moodle 1.7.2==<br /> <br /> 30th March, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10174 This page shows issues resolved in this version]<br /> <br /> ===Security===<br /> <br /> * Unintended logouts are now prevented - sesskey added to logout.php script<br /> * Fixed problem with visible posts in user profile when &quot;forceloginforprofiles&quot; disabled<br /> * Fixed visibility of site blog entries<br /> * Corrected wrong includes in lams<br /> * XSS injection in SCORM 1.2 reports<br /> * Fixed old problem with approvals in Data module, edited entries were approved automatically<br /> * Fixed escaping in shell commands (Win32 platform only)<br /> * Fixed visibility of blog drafts<br /> * Rewritten parameter handling in repository plugin<br /> * Fixed XSS in login block<br /> <br /> ==Moodle 1.7.1==<br /> <br /> 17th January, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10151 This page shows details about issues resolved in this version]<br /> <br /> ==Moodle 1.7==<br /> <br /> 7th November, 2006<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10120&amp;styleName=Html&amp;projectId=10011&amp;Create=Create This page shows details about issues resolved in this version] <br /> <br /> ===Headline features=== <br /> <br /> * [[Roles]] <br /> :: Permissions based on fine-grained capabilities allow all kinds of roles to be created and assigned in all contexts around Moodle. This creates a great deal more flexibility in the permissions that you can grant to people. <br /> * [[Development:XMLDB Documentation|XML Database Schema]] <br /> :: added support for MS-SQL and Oracle with more databases to come. Developers now have just one XML file to edit when changing the database structure, and there is even a very funky editor for this file built-in to Moodle <br /> * New Admin interface <br /> :: Completely new admin interface, with accessible design and cool features to make access to settings fast and easy. <br /> * [[Unit tests|Unit testing framework]] <br /> :: Making it easier for developers to write test code, which should ultimately lead to a more reliable Moodle. <br /> * [[AJAX]] Course editing (STILL UNSTABLE IN 1.7 RELEASE AND OFF BY DEFAULT, USE WITH CAUTION!) <br /> :: The Topics and Weekly course formats now feature AJAX editing which means you can drag drop blocks, activities and sections (weeks/topics) and it all happens instantly. No more page reloading!<br /> <br /> ===Module improvements=== <br /> <br /> * Improvements to the [[Assignment module]] <br /> **New type Advanced uploading of files <br /> <br /> * Improvements to the [[Database module]] <br /> **Template/Field settings can now be saved as Presets and shared across a site. <br /> **Presets are just zip files, and can also be shared between sites. <br /> **Moodle 1.7 comes with one sample preset (an Image Gallery) with more to come. <br /> **New latitude/longitude data type <br /> <br /> * Improvements to the [[Lesson module]] <br /> **Now has a more unified view of lesson screens. <br /> **Teacher editing: <br /> ***Collapsed view has a nicer format, displays more information regarding each page and allows the creation of new pages. <br /> ***Editing is now speedier by replacing 3 second redirect delays with a notification system. <br /> **New feature: display default feedback. <br /> ***Default is '''On''' so previous lessons behave as before. <br /> ***Description: if no ''response'' is entered for a question answer and this setting is turned '''Off''', then the user skips the feedback page. <br /> **Graceful degrade of JavaScript. <br /> **Several bug fixes. <br /> <br /> * Improvements to the [[Quiz module]] <br /> :* The teacher can configure comments that are displayed to the student at the end of their attempt, with the comment displayed depending on the student's score. <br /> <br /> * Improvements to some core question types <br /> :* All question types can now have some general feedback. This is displayed to all students after they have finished the question (depending on the quiz settings) and does not depend on what response the student gave. Use this to tell the student what the question was about, or link them to more information about the topic it covers. <br /> :* [[Matching question type|Matching]] questions can have extra wrong answers, and work when two questions have the same answer. <br /> :* [[Multiple Choice question type|Multiple Choice]] questions can have feedback for the whole question, as well as specific answers. This is particularly useful for multiple-response questions. <br /> :* [[Numerical question type|Numerical]] questions can have different answers with different precisions and scores. (Previously this was only supported via GIFT import. Now you can edit questions like this.) <br /> <br /> * Improvements to the [[Wiki module]] <br /> :* While editing a wiki page it is now locked so that others cannot try to change it at the same time. Teachers can override the lock. <br /> :* Minor bugfixes (mostly to fix problems that occured when using Postgres database). <br /> <br /> ===Enrolment plugin improvements=== <br /> <br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :*Accepts 'Electronic Checks (ACH)'. After a user approving echeck, an admin who has upload csv capacity must import a CSV file to get the user enrolled in the Payment Management page. <br /> :*Autoconfigures credit card and echeck types if the merchant does not accept some types of them.<br /> <br /> == See also ==<br /> *[[Old releases|Old release notes]]<br /> <br /> [[es:Notas de versiones]]<br /> [[fr:Notes de mise à jour]]<br /> [[pt:Versões do Moodle]]<br /> [[ru:Примечания к версиям]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Latest_release_notes&diff=25252 2007-12-27T21:32:10Z

<p>Martinlanghoff: /* Headline features */</p> <hr /> <div>{{About Moodle}}<br /> <br /> ==Moodle 1.9 Beta==<br /> <br /> Released: 14th August 2007<br /> <br /> This is a DEVELOPMENT RELEASE made available for wider testing by the community in preparation for a polished release of 1.9 in the coming weeks. It should not be used for production sites unless you are prepared to report the bugs you find in the [http://tracker.moodle.org Moodle Tracker], hopefully with your patches attached. :-)<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10190 the full list of fixed issues in 1.9 so far].<br /> <br /> ===Headline features===<br /> <br /> * [[Development:Grades|Gradebook]] - Moodle.com (funded by Open University)<br /> :: Completely rewritten from scratch for speed and flexibility. The new gradebook consists of plugins for reports, imports and exports. There are a number of standard reports which are useful for graders, students etc. The grader report allows you to treat the gradebook much more like a spreadsheet with manual editing, calculations, aggregations, weighting, locking, hiding, textual notes and so on.<br /> * [[Development:Outcomes|Outcomes]] - Moodle.com<br /> :: You can also now develop a list of expected outcomes (competencies) and connect these to courses and activities. You can even grade against multiple outcomes at once (ie Rubrics).<br /> * [[Development:Events|Events API]] - Moodle.com<br /> ::The new Events API provides a way for any code to &quot;hook&quot; into events in a clean, loosely coupled way. It's the foundation of the new gradebook. A lot of events in Moodle (such as adding a user or a course) now trigger events that developers can hook into.<br /> * [[Development:Scalability|Scalability and performance improvements]] improvements - Catalyst Ltd<br /> ::A complete overhaul of the [[Roles]] implementation for correctness and scalability. Large sites with thousands of courses and users now load quickly and behave well under heavy traffic, thanks to reworked code for Roles. Additional boost for sites using PHP precompilers and significant improvements in the DB access code in all databases.<br /> * [[Tags]] - Luiz Cruz ([[Student_projects/Social_Networking_features|GSOC Social Networking project]])<br /> :: Allows users to describe their own interests in terms of tags, which creates interest pages around those tags, bringing information together from a variety of sources.<br /> * [[Question_Engine_Changes_in_Moodle_1.9|Improved question bank]] - Jamie Pratt funded by [http://www.fun.ac.jp/en/ Future University Hakodate].<br /> ::Allows questions to be shared by the whole site, a course category, a single course, or be kept private to a single module. More control over who can do what to each question. Improved file management for files linked to by questions.<br /> * [[Notes]] - Andrei Bautu ([[Student projects/User Management Improvements|GSOC User Management Improvements project]])<br /> :: Detailed notes can be kept about individual users (for example teachers might want to keep and share notes about students in their class).<br /> * [[Bulk user actions]] - Andrei Bautu ([[Student projects/User Management Improvements|GSOC User Management Improvements project]])<br /> ::Administrators can perform bulk user actions, such as the mass deletion of user accounts. Extended features in the bulk user upload script to allow generation of user fields based on templates. <br /> * New Custom Corners theme - Urs Hunkler<br /> :: Beautiful and curvy (in all browsers).<br /> <br /> ===Other major improvements===<br /> <br /> * [[Groups]] and [[Groupings]]<br /> :: New support for groupings (groups of groups) which was added briefly and then removed from 1.8.x. Activities and resources may be assigned to particular groupings.<br /> * New theme settings<br /> ** Category themes - can now set the theme for a category which will apply to all sub-categories and courses<br /> ** Theme order - new setting ''$CFG-&gt;themeorder'' which sets the priority of the themes from highest to lowest.<br /> * Ability to control block visibility with roles<br /> ** A new [[Capabilities/moodle/block:view|moodle/block:view]] capability has been added which allows control of who can view blocks from the roles system. This allows certain blocks to be hidden from the guest user, for example. See [[Block_permissions|Hiding blocks from certain users]].<br /> <br /> ===Module improvements===<br /> <br /> * Quiz/Question improvements:<br /> ** Improved question bank, as above.<br /> ** Quizzes now listed on the MyMoodle page. (Implemented by Stephen Bourget and Tim Hunt.)<br /> ** A quiz can now [[Quiz submission email notification|send emails when an attempt is finished]] - a confirmation to the student, a notification to all teachers, or both. (Implemented by Graham Miller of [http://www.webenhanced.com.au/ Web Enhanced Solutions] and Tim Hunt.)<br /> ** Third party question types can now implement Moodle XML and other import and export format. (Implemented by Howard Miller.)<br /> ** Gift Import/Export format can now handle Essay and Description question types.<br /> ** Some slight improvements to quiz layout. See [http://tracker.moodle.org/browse/MDL-10374 MDL-10374] for details. Theme designers please note.<br /> ** Multiple choice questions now show the feedback for all the options to students on the review page after the attempt is over.<br /> <br /> ''Developers please add news here!''<br /> <br /> ===Notes===<br /> <br /> * In the new accesslib there is a subtle difference in how we resolve conflicts between 'allow' and 'prevent' capabilities. See [[Development:Roles#Capability-locality_changes_in_v1.9|Capability-locality changes in 1.9]].<br /> <br /> ==Moodle 1.8.3==<br /> <br /> Released: 11th October 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10230&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.3].<br /> <br /> ===Highlights===<br /> * Some crucial performance fixes<br /> * Many little annoying bugs squashed<br /> <br /> <br /> <br /> ==Moodle 1.8.2==<br /> <br /> Released: 8th July 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10220&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.2].<br /> <br /> ===Highlights===<br /> * Two XSS security vulnerabilities (one reported in the wild) were fixed.<br /> <br /> ==Moodle 1.8.1==<br /> <br /> Released: 14th June 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10213&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.1].<br /> <br /> ===Highlights===<br /> * The groups implementation has been cleaned up somewhat from the 1.8 release. The '''groupings''' GUI that appeared in 1.8 has been removed, because groupings are not complete and should not be used yet. Moodle 1.8 sites that have created groupings should upgrade to 1.8.1 to have groupings reset ... otherwise there could be problem when upgrading to the real groupings in 1.9 or later.<br /> <br /> ==Moodle 1.8==<br /> <br /> Released: 31st March 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10130 the full list of fixed issues in 1.8].<br /> <br /> ===Headline features===<br /> <br /> * [[Accessibility]] - Moodle.com <br /> :: The Moodle interface is now compliant with XHTML Strict 1.0 and major accessibility standards.<br /> * [[Moodle Network]] - Catalyst, Richard Wyles<br /> :: We can now set up peer Moodle installations allowing users to roam from one site to another, using comprehensive SSO and transparent remote enrolments. Administrators at the originating Moodle install can see logs of remote activity. You can also run your Moodle in &quot;Hub&quot; mode where any Moodle install can connect and users roam across.<br /> * [[Web Services API]] - Catalyst, Richard Wyles<br /> :: The Moodle Network code includes an XML-RPC call dispatcher that can expose the WHOLE Moodle API to trusted hosts. We will building on this in further versions but you can start using it now if you need to.<br /> * [[Development:lib/formslib.php|Moodle forms library]] - Moodle.com <br /> :: Majority of forms now use a single API for defining forms consistently and collecting data safely without using any HTML at all.<br /> * [[Multi Authentication]] - Iñaki Arenaza / Catalyst / Moodle.com<br /> :: It is now easier to configure multiple sources of authentication at once. WARNING: the format for authentication plugins has changed, so custom plugins may be broken, however it's very easy to convert old code to the new format. More details can be found in /auth/README.txt.<br /> * [[Development:Customisable user profiles|Customisable User Profiles]] - Pukunui Technology<br /> ::Allow new arbitrary fields to be added to the user profile, with more control over what fields appear on what signup and profile editing screens.<br /> * Groups refactor - OU / Moodle.com<br /> ::Groups code has been reorganised to make it more flexible for the future (see 1.9). <br /> * [http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&amp;requestId=10221 Roles improvements] - Moodle.com<br /> :: In addition to many Roles fixes and refinements, Moodle 1.8 has separated the SYSTEM context from the SITE context (which makes it more like 1.6 used to work). The SITE context is the &quot;front page course&quot; and its activities. This should make it easier for admins to set up permissions. Login as and switching of roles was rewritten. Administrators can view recommended permission settings of legacy roles and may reset legacy roles to defaults.<br /> * [http://tracker.moodle.org/browse/MDL-7993 Support for ODS export] - Moodle.com<br /> ::Open Document Format should solve majority of current problems with exports into proprietary Excel format. You may need to install special import plugin if you are using MS Office.<br /> <br /> ===Known problems===<br /> * CAS auth not working<br /> <br /> ===Module improvements===<br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :: Payment managers can obtain an authorization code over phone from customer's bank if the credit card of the user cannot be captured on the internet directly.<br /> <br /> ''Developers please add news here!''<br /> <br /> ===See also===<br /> *[[Upgrading to Moodle 1.8]]<br /> <br /> ==Moodle 1.7.3==<br /> <br /> 11th October, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10212&amp;styleName=Html&amp;projectId=10011 This page shows issues resolved in this version]<br /> <br /> <br /> ==Moodle 1.7.2==<br /> <br /> 30th March, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10174 This page shows issues resolved in this version]<br /> <br /> ===Security===<br /> <br /> * Unintended logouts are now prevented - sesskey added to logout.php script<br /> * Fixed problem with visible posts in user profile when &quot;forceloginforprofiles&quot; disabled<br /> * Fixed visibility of site blog entries<br /> * Corrected wrong includes in lams<br /> * XSS injection in SCORM 1.2 reports<br /> * Fixed old problem with approvals in Data module, edited entries were approved automatically<br /> * Fixed escaping in shell commands (Win32 platform only)<br /> * Fixed visibility of blog drafts<br /> * Rewritten parameter handling in repository plugin<br /> * Fixed XSS in login block<br /> <br /> ==Moodle 1.7.1==<br /> <br /> 17th January, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10151 This page shows details about issues resolved in this version]<br /> <br /> ==Moodle 1.7==<br /> <br /> 7th November, 2006<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10120&amp;styleName=Html&amp;projectId=10011&amp;Create=Create This page shows details about issues resolved in this version] <br /> <br /> ===Headline features=== <br /> <br /> * [[Roles]] <br /> :: Permissions based on fine-grained capabilities allow all kinds of roles to be created and assigned in all contexts around Moodle. This creates a great deal more flexibility in the permissions that you can grant to people. <br /> * [[Development:XMLDB Documentation|XML Database Schema]] <br /> :: added support for MS-SQL and Oracle with more databases to come. Developers now have just one XML file to edit when changing the database structure, and there is even a very funky editor for this file built-in to Moodle <br /> * New Admin interface <br /> :: Completely new admin interface, with accessible design and cool features to make access to settings fast and easy. <br /> * [[Unit tests|Unit testing framework]] <br /> :: Making it easier for developers to write test code, which should ultimately lead to a more reliable Moodle. <br /> * [[AJAX]] Course editing (STILL UNSTABLE IN 1.7 RELEASE AND OFF BY DEFAULT, USE WITH CAUTION!) <br /> :: The Topics and Weekly course formats now feature AJAX editing which means you can drag drop blocks, activities and sections (weeks/topics) and it all happens instantly. No more page reloading!<br /> <br /> ===Module improvements=== <br /> <br /> * Improvements to the [[Assignment module]] <br /> **New type Advanced uploading of files <br /> <br /> * Improvements to the [[Database module]] <br /> **Template/Field settings can now be saved as Presets and shared across a site. <br /> **Presets are just zip files, and can also be shared between sites. <br /> **Moodle 1.7 comes with one sample preset (an Image Gallery) with more to come. <br /> **New latitude/longitude data type <br /> <br /> * Improvements to the [[Lesson module]] <br /> **Now has a more unified view of lesson screens. <br /> **Teacher editing: <br /> ***Collapsed view has a nicer format, displays more information regarding each page and allows the creation of new pages. <br /> ***Editing is now speedier by replacing 3 second redirect delays with a notification system. <br /> **New feature: display default feedback. <br /> ***Default is '''On''' so previous lessons behave as before. <br /> ***Description: if no ''response'' is entered for a question answer and this setting is turned '''Off''', then the user skips the feedback page. <br /> **Graceful degrade of JavaScript. <br /> **Several bug fixes. <br /> <br /> * Improvements to the [[Quiz module]] <br /> :* The teacher can configure comments that are displayed to the student at the end of their attempt, with the comment displayed depending on the student's score. <br /> <br /> * Improvements to some core question types <br /> :* All question types can now have some general feedback. This is displayed to all students after they have finished the question (depending on the quiz settings) and does not depend on what response the student gave. Use this to tell the student what the question was about, or link them to more information about the topic it covers. <br /> :* [[Matching question type|Matching]] questions can have extra wrong answers, and work when two questions have the same answer. <br /> :* [[Multiple Choice question type|Multiple Choice]] questions can have feedback for the whole question, as well as specific answers. This is particularly useful for multiple-response questions. <br /> :* [[Numerical question type|Numerical]] questions can have different answers with different precisions and scores. (Previously this was only supported via GIFT import. Now you can edit questions like this.) <br /> <br /> * Improvements to the [[Wiki module]] <br /> :* While editing a wiki page it is now locked so that others cannot try to change it at the same time. Teachers can override the lock. <br /> :* Minor bugfixes (mostly to fix problems that occured when using Postgres database). <br /> <br /> ===Enrolment plugin improvements=== <br /> <br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :*Accepts 'Electronic Checks (ACH)'. After a user approving echeck, an admin who has upload csv capacity must import a CSV file to get the user enrolled in the Payment Management page. <br /> :*Autoconfigures credit card and echeck types if the merchant does not accept some types of them.<br /> <br /> == See also ==<br /> *[[Old releases|Old release notes]]<br /> <br /> [[es:Notas de versiones]]<br /> [[fr:Notes de mise à jour]]<br /> [[pt:Versões do Moodle]]<br /> [[ru:Примечания к версиям]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Latest_release_notes&diff=25251 2007-12-27T20:06:06Z

<p>Martinlanghoff: /* Headline features */</p> <hr /> <div>{{About Moodle}}<br /> <br /> ==Moodle 1.9 Beta==<br /> <br /> Released: 14th August 2007<br /> <br /> This is a DEVELOPMENT RELEASE made available for wider testing by the community in preparation for a polished release of 1.9 in the coming weeks. It should not be used for production sites unless you are prepared to report the bugs you find in the [http://tracker.moodle.org Moodle Tracker], hopefully with your patches attached. :-)<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10190 the full list of fixed issues in 1.9 so far].<br /> <br /> ===Headline features===<br /> <br /> * [[Development:Grades|Gradebook]] - Moodle.com (funded by Open University)<br /> :: Completely rewritten from scratch for speed and flexibility. The new gradebook consists of plugins for reports, imports and exports. There are a number of standard reports which are useful for graders, students etc. The grader report allows you to treat the gradebook much more like a spreadsheet with manual editing, calculations, aggregations, weighting, locking, hiding, textual notes and so on.<br /> * [[Development:Outcomes|Outcomes]] - Moodle.com<br /> :: You can also now develop a list of expected outcomes (competencies) and connect these to courses and activities. You can even grade against multiple outcomes at once (ie Rubrics).<br /> * [[Development:Events|Events API]] - Moodle.com<br /> ::The new Events API provides a way for any code to &quot;hook&quot; into events in a clean, loosely coupled way. It's the foundation of the new gradebook. A lot of events in Moodle (such as adding a user or a course) now trigger events that developers can hook into.<br /> * [[Development:Scalability]] improvements - Catalyst Ltd<br /> ::A complete overhaul of the [[Roles]] implementation for correctness and scalability. Large sites with thousands of courses and users now load quickly and behave well under heavy traffic, thanks to reworked code for Roles. Additional boost for sites using PHP precompilers and significant improvements in the DB access code in all databases.<br /> * [[Tags]] - Luiz Cruz ([[Student_projects/Social_Networking_features|GSOC Social Networking project]])<br /> :: Allows users to describe their own interests in terms of tags, which creates interest pages around those tags, bringing information together from a variety of sources.<br /> * [[Question_Engine_Changes_in_Moodle_1.9|Improved question bank]] - Jamie Pratt funded by [http://www.fun.ac.jp/en/ Future University Hakodate].<br /> ::Allows questions to be shared by the whole site, a course category, a single course, or be kept private to a single module. More control over who can do what to each question. Improved file management for files linked to by questions.<br /> * [[Notes]] - Andrei Bautu ([[Student projects/User Management Improvements|GSOC User Management Improvements project]])<br /> :: Detailed notes can be kept about individual users (for example teachers might want to keep and share notes about students in their class).<br /> * [[Bulk user actions]] - Andrei Bautu ([[Student projects/User Management Improvements|GSOC User Management Improvements project]])<br /> ::Administrators can perform bulk user actions, such as the mass deletion of user accounts. Extended features in the bulk user upload script to allow generation of user fields based on templates. <br /> * New Custom Corners theme - Urs Hunkler<br /> :: Beautiful and curvy (in all browsers).<br /> <br /> ===Other major improvements===<br /> <br /> * [[Groups]] and [[Groupings]]<br /> :: New support for groupings (groups of groups) which was added briefly and then removed from 1.8.x. Activities and resources may be assigned to particular groupings.<br /> * New theme settings<br /> ** Category themes - can now set the theme for a category which will apply to all sub-categories and courses<br /> ** Theme order - new setting ''$CFG-&gt;themeorder'' which sets the priority of the themes from highest to lowest.<br /> * Ability to control block visibility with roles<br /> ** A new [[Capabilities/moodle/block:view|moodle/block:view]] capability has been added which allows control of who can view blocks from the roles system. This allows certain blocks to be hidden from the guest user, for example. See [[Block_permissions|Hiding blocks from certain users]].<br /> <br /> ===Module improvements===<br /> <br /> * Quiz/Question improvements:<br /> ** Improved question bank, as above.<br /> ** Quizzes now listed on the MyMoodle page. (Implemented by Stephen Bourget and Tim Hunt.)<br /> ** A quiz can now [[Quiz submission email notification|send emails when an attempt is finished]] - a confirmation to the student, a notification to all teachers, or both. (Implemented by Graham Miller of [http://www.webenhanced.com.au/ Web Enhanced Solutions] and Tim Hunt.)<br /> ** Third party question types can now implement Moodle XML and other import and export format. (Implemented by Howard Miller.)<br /> ** Gift Import/Export format can now handle Essay and Description question types.<br /> ** Some slight improvements to quiz layout. See [http://tracker.moodle.org/browse/MDL-10374 MDL-10374] for details. Theme designers please note.<br /> ** Multiple choice questions now show the feedback for all the options to students on the review page after the attempt is over.<br /> <br /> ''Developers please add news here!''<br /> <br /> ===Notes===<br /> <br /> * In the new accesslib there is a subtle difference in how we resolve conflicts between 'allow' and 'prevent' capabilities. See [[Development:Roles#Capability-locality_changes_in_v1.9|Capability-locality changes in 1.9]].<br /> <br /> ==Moodle 1.8.3==<br /> <br /> Released: 11th October 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10230&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.3].<br /> <br /> ===Highlights===<br /> * Some crucial performance fixes<br /> * Many little annoying bugs squashed<br /> <br /> <br /> <br /> ==Moodle 1.8.2==<br /> <br /> Released: 8th July 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10220&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.2].<br /> <br /> ===Highlights===<br /> * Two XSS security vulnerabilities (one reported in the wild) were fixed.<br /> <br /> ==Moodle 1.8.1==<br /> <br /> Released: 14th June 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10213&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.1].<br /> <br /> ===Highlights===<br /> * The groups implementation has been cleaned up somewhat from the 1.8 release. The '''groupings''' GUI that appeared in 1.8 has been removed, because groupings are not complete and should not be used yet. Moodle 1.8 sites that have created groupings should upgrade to 1.8.1 to have groupings reset ... otherwise there could be problem when upgrading to the real groupings in 1.9 or later.<br /> <br /> ==Moodle 1.8==<br /> <br /> Released: 31st March 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10130 the full list of fixed issues in 1.8].<br /> <br /> ===Headline features===<br /> <br /> * [[Accessibility]] - Moodle.com <br /> :: The Moodle interface is now compliant with XHTML Strict 1.0 and major accessibility standards.<br /> * [[Moodle Network]] - Catalyst, Richard Wyles<br /> :: We can now set up peer Moodle installations allowing users to roam from one site to another, using comprehensive SSO and transparent remote enrolments. Administrators at the originating Moodle install can see logs of remote activity. You can also run your Moodle in &quot;Hub&quot; mode where any Moodle install can connect and users roam across.<br /> * [[Web Services API]] - Catalyst, Richard Wyles<br /> :: The Moodle Network code includes an XML-RPC call dispatcher that can expose the WHOLE Moodle API to trusted hosts. We will building on this in further versions but you can start using it now if you need to.<br /> * [[Development:lib/formslib.php|Moodle forms library]] - Moodle.com <br /> :: Majority of forms now use a single API for defining forms consistently and collecting data safely without using any HTML at all.<br /> * [[Multi Authentication]] - Iñaki Arenaza / Catalyst / Moodle.com<br /> :: It is now easier to configure multiple sources of authentication at once. WARNING: the format for authentication plugins has changed, so custom plugins may be broken, however it's very easy to convert old code to the new format. More details can be found in /auth/README.txt.<br /> * [[Development:Customisable user profiles|Customisable User Profiles]] - Pukunui Technology<br /> ::Allow new arbitrary fields to be added to the user profile, with more control over what fields appear on what signup and profile editing screens.<br /> * Groups refactor - OU / Moodle.com<br /> ::Groups code has been reorganised to make it more flexible for the future (see 1.9). <br /> * [http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&amp;requestId=10221 Roles improvements] - Moodle.com<br /> :: In addition to many Roles fixes and refinements, Moodle 1.8 has separated the SYSTEM context from the SITE context (which makes it more like 1.6 used to work). The SITE context is the &quot;front page course&quot; and its activities. This should make it easier for admins to set up permissions. Login as and switching of roles was rewritten. Administrators can view recommended permission settings of legacy roles and may reset legacy roles to defaults.<br /> * [http://tracker.moodle.org/browse/MDL-7993 Support for ODS export] - Moodle.com<br /> ::Open Document Format should solve majority of current problems with exports into proprietary Excel format. You may need to install special import plugin if you are using MS Office.<br /> <br /> ===Known problems===<br /> * CAS auth not working<br /> <br /> ===Module improvements===<br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :: Payment managers can obtain an authorization code over phone from customer's bank if the credit card of the user cannot be captured on the internet directly.<br /> <br /> ''Developers please add news here!''<br /> <br /> ===See also===<br /> *[[Upgrading to Moodle 1.8]]<br /> <br /> ==Moodle 1.7.3==<br /> <br /> 11th October, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10212&amp;styleName=Html&amp;projectId=10011 This page shows issues resolved in this version]<br /> <br /> <br /> ==Moodle 1.7.2==<br /> <br /> 30th March, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10174 This page shows issues resolved in this version]<br /> <br /> ===Security===<br /> <br /> * Unintended logouts are now prevented - sesskey added to logout.php script<br /> * Fixed problem with visible posts in user profile when &quot;forceloginforprofiles&quot; disabled<br /> * Fixed visibility of site blog entries<br /> * Corrected wrong includes in lams<br /> * XSS injection in SCORM 1.2 reports<br /> * Fixed old problem with approvals in Data module, edited entries were approved automatically<br /> * Fixed escaping in shell commands (Win32 platform only)<br /> * Fixed visibility of blog drafts<br /> * Rewritten parameter handling in repository plugin<br /> * Fixed XSS in login block<br /> <br /> ==Moodle 1.7.1==<br /> <br /> 17th January, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10151 This page shows details about issues resolved in this version]<br /> <br /> ==Moodle 1.7==<br /> <br /> 7th November, 2006<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10120&amp;styleName=Html&amp;projectId=10011&amp;Create=Create This page shows details about issues resolved in this version] <br /> <br /> ===Headline features=== <br /> <br /> * [[Roles]] <br /> :: Permissions based on fine-grained capabilities allow all kinds of roles to be created and assigned in all contexts around Moodle. This creates a great deal more flexibility in the permissions that you can grant to people. <br /> * [[Development:XMLDB Documentation|XML Database Schema]] <br /> :: added support for MS-SQL and Oracle with more databases to come. Developers now have just one XML file to edit when changing the database structure, and there is even a very funky editor for this file built-in to Moodle <br /> * New Admin interface <br /> :: Completely new admin interface, with accessible design and cool features to make access to settings fast and easy. <br /> * [[Unit tests|Unit testing framework]] <br /> :: Making it easier for developers to write test code, which should ultimately lead to a more reliable Moodle. <br /> * [[AJAX]] Course editing (STILL UNSTABLE IN 1.7 RELEASE AND OFF BY DEFAULT, USE WITH CAUTION!) <br /> :: The Topics and Weekly course formats now feature AJAX editing which means you can drag drop blocks, activities and sections (weeks/topics) and it all happens instantly. No more page reloading!<br /> <br /> ===Module improvements=== <br /> <br /> * Improvements to the [[Assignment module]] <br /> **New type Advanced uploading of files <br /> <br /> * Improvements to the [[Database module]] <br /> **Template/Field settings can now be saved as Presets and shared across a site. <br /> **Presets are just zip files, and can also be shared between sites. <br /> **Moodle 1.7 comes with one sample preset (an Image Gallery) with more to come. <br /> **New latitude/longitude data type <br /> <br /> * Improvements to the [[Lesson module]] <br /> **Now has a more unified view of lesson screens. <br /> **Teacher editing: <br /> ***Collapsed view has a nicer format, displays more information regarding each page and allows the creation of new pages. <br /> ***Editing is now speedier by replacing 3 second redirect delays with a notification system. <br /> **New feature: display default feedback. <br /> ***Default is '''On''' so previous lessons behave as before. <br /> ***Description: if no ''response'' is entered for a question answer and this setting is turned '''Off''', then the user skips the feedback page. <br /> **Graceful degrade of JavaScript. <br /> **Several bug fixes. <br /> <br /> * Improvements to the [[Quiz module]] <br /> :* The teacher can configure comments that are displayed to the student at the end of their attempt, with the comment displayed depending on the student's score. <br /> <br /> * Improvements to some core question types <br /> :* All question types can now have some general feedback. This is displayed to all students after they have finished the question (depending on the quiz settings) and does not depend on what response the student gave. Use this to tell the student what the question was about, or link them to more information about the topic it covers. <br /> :* [[Matching question type|Matching]] questions can have extra wrong answers, and work when two questions have the same answer. <br /> :* [[Multiple Choice question type|Multiple Choice]] questions can have feedback for the whole question, as well as specific answers. This is particularly useful for multiple-response questions. <br /> :* [[Numerical question type|Numerical]] questions can have different answers with different precisions and scores. (Previously this was only supported via GIFT import. Now you can edit questions like this.) <br /> <br /> * Improvements to the [[Wiki module]] <br /> :* While editing a wiki page it is now locked so that others cannot try to change it at the same time. Teachers can override the lock. <br /> :* Minor bugfixes (mostly to fix problems that occured when using Postgres database). <br /> <br /> ===Enrolment plugin improvements=== <br /> <br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :*Accepts 'Electronic Checks (ACH)'. After a user approving echeck, an admin who has upload csv capacity must import a CSV file to get the user enrolled in the Payment Management page. <br /> :*Autoconfigures credit card and echeck types if the merchant does not accept some types of them.<br /> <br /> == See also ==<br /> *[[Old releases|Old release notes]]<br /> <br /> [[es:Notas de versiones]]<br /> [[fr:Notes de mise à jour]]<br /> [[pt:Versões do Moodle]]<br /> [[ru:Примечания к версиям]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Roles&diff=3163 2007-09-19T04:07:53Z

<p>Martinlanghoff: /* Capability-locality changes in v1.9 */</p> <hr /> <div>{{Moodle 1.7}}<br /> '''Roles and permissions''' is in Moodle 1.7 onwards.<br /> <br /> ==Definitions==<br /> <br /> A role is an identifier of the user's status in some context. For example: Teacher, Student and Forum moderator are examples of roles.<br /> <br /> A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example, ''mod/forum:replypost'' is a capability.<br /> <br /> A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.<br /> <br /> A context is a &quot;space&quot; in the Moodle, such as courses, activity modules, blocks etc.<br /> <br /> ==The existing system==<br /> <br /> In versions prior to v1.7, Moodle uses a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can perform are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.<br /> <br /> ==The new roles and capability system==<br /> <br /> With v1.7 and greater, Moodle introduces a roles and capabilities system.<br /> <br /> Role has two primary functions:<br /> # define list of permissions - role definition is global for all contexts, but can be changed by local context overrides<br /> # replace old course enrolments - role assignment in course context is simitar to the old enrolment process<br /> <br /> The new system will allow authorized users to define an arbitrary number of roles (eg a teacher) <br /> <br /> A role consists of a list of permissions for different possible actions within Moodle (eg delete discussions, add activities etc)<br /> <br /> Roles can be applied to users in a context (eg assign Fred as a teacher in a particular course)<br /> <br /> Here are the possible contexts, listed from the most general to the most specific. <br /> <br /> #CONTEXT_SYSTEM -- the whole site<br /> #CONTEXT_PERSONAL -- yourself<br /> #CONTEXT_USER -- another user<br /> #CONTEXT_COURSECAT -- a course category<br /> #CONTEXT_COURSE -- a course<br /> '''#CONTEXT_GROUP -- a group<br /> #CONTEXT_MODULE -- an activity module<br /> #CONTEXT_BLOCK -- a block<br /> <br /> [[Image:Moodle-contexts-1.8.png|right|thumb|A diagram of the contexts in Moodle 1.8, based on the [[Talk:Roles_and_capabilities|text diagram by Martin Dougiamas]]. Click on the diagram to see a more detailed view of it.]]<br /> <br /> An authorized user will be able to assign an arbitrary number of roles to each user in any context.<br /> <br /> Capabilities can have the following permissions:<br /> <br /> #CAP_INHERIT<br /> #CAP_ALLOW<br /> #CAP_PREVENT<br /> #CAP_PROHIBIT<br /> <br /> If no permission is defined, then the capability permission is inherited from a context that is more general than the current context. If we define different permission values for the same capability in different contexts, we say that we are overriding the capability in the more specific context.<br /> <br /> Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by enforcing the rule that the capability defined for a more specific context will win, unless a prohibit is encountered in a less specific context.<br /> <br /> For example, Mark has a student role at course level, which allows him to write into a wiki. But Mark also got assigned a Visitor role at a module context level (for a particular wiki) which prevents him from writing to the wiki (read only). Therefore, for this particular wiki, Mark will not be able to write to the wiki since the more specific context wins.<br /> <br /> If we set a PROHIBIT on a capability, it means that the capability cannot be overridden and will ALWAYS have a permission of prevent (deny). Prohibit always wins. For example, Jeff has a naughty student role that prohibits him from postings in any forums (for the whole site), but he's also assigned a facilitator role in &quot;Science forum&quot; in the course Science and Math 101. Since prohibit always wins, Jeff is unable to post in &quot;Science forum&quot;.<br /> <br /> Allow and prevent will cancel each other out if set for the same capability at the same context level. If this happens, we refer to the previous context level to determine the permission for the capability.<br /> <br /> This may sound more complex than it really is in practice. The upshot is that the system can be flexible enough to allow pretty much any combination of permissions.<br /> <br /> ===Capability-locality changes in v1.9===<br /> <br /> When resolving conflicts between &quot;allow&quot; and &quot;prevent&quot; in v1.7 and v1.8 the locality of the capability is taken into account, although with less weight than the locality of the role assignment. In v1.9 the process has been simplified, we consider locality of the role assignment when dealing with allow/prevent conflicts, but ignore where the capability has been defined (as long as it applies to the context).<br /> <br /> For example - for the situation where there is<br /> <br /> * two roles assigned to one user in a context (eg student role and teacher role)<br /> * one override on one of those roles ( eg student role), at the same context<br /> <br /> then<br /> <br /> * '''1.7/1.8''' The override used to ''always'' win over the settings from the combined roles.<br /> <br /> * '''1.9''' The override is combined with the student role first. and then the roles are combined. This is more logical, as the override is acting like a modification to the student role.<br /> <br /> For more details, see [http://tracker.moodle.org/browse/MDL-11218 MDL-11218]<br /> <br /> ==Upgrading from 1.6==<br /> <br /> A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the existing capabilities will be automatically retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, mirroring what we have in 1.6. With no modifications, Moodle will operate exactly the same before and after the upgrade.<br /> <br /> ===Admins===<br /> <br /> Admin users will be assigned the default legacy admin role in the system (site) context<br /> <br /> ===Course Creators===<br /> <br /> Course Creators will be assigned the default legacy course creator role in the system (site) context<br /> <br /> ===Teachers===<br /> <br /> Users who were teachers will be assigned the default legacy teacher role (or non-editing teacher role) in all courses they were teacher.<br /> <br /> ===Students===<br /> <br /> Users who were students will be assigned the default student role in all courses they were student.<br /> <br /> ===Guests===<br /> <br /> There will still be a single guest user with no default role at site level. For each course that allows guest access, the guest role will be assigned to the guest user for that course context. The guest control for the course will be modified from three to two options (guests always need to enter enrolment key - on/off). This setting is checked as now to force guests to enter key.<br /> <br /> ==Capabilities==<br /> <br /> This will be a comprehensive list of capabilities (it's not complete yet). It is important that capability names are unique.<br /> <br /> ===Core-level Capabilities===<br /> <br /> Moodle core capability names start with 'moodle/'. The next word indicates what type of core capability it is, and the last word is the actual capability itself. The capabilities for the Moodle core are defined in lib/db/access.php<br /> <br /> #moodle/legacy:guest - legacy capabilities are used to transition existing users to the new roles system during the upgrade to Moodle 1.7<br /> #moodle/legacy:student<br /> #moodle/legacy:teacher<br /> #moodle/legacy:editingteacher<br /> #moodle/legacy:coursecreator<br /> #moodle/legacy:admin<br /> #moodle/site:doanything - special capability, meant for admins, if is set, overrides all other capability settings<br /> #moodle/site:config - applicable in admin/index.php and config.php (might break down later) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()<br /> #moodle/site:readallmessages - reads all messages and history<br /> #moodle/site:approvecourse - approves a pending course<br /> #moodle/site:manageblocks - adding/removing/editing blocks (site, course contexts only for now) : 1)_add_edit_controls moodleblock.class.php <br /> #moodle/site:backup - can create a course backup : 1)course/category.php 2)block_admin.php<br /> #moodle/site:restore - can restore into this context : 1)course/category.php 2)block_admin.php<br /> #moodle/site:import - can import other courses into this context : 1)block_admin.php<br /> #moodle/site:accessallgroups - able to access all groups irrespective of what group the user is in<br /> #moodle/site:accessdb - directly accessing db (phpmyadmin)<br /> #moodle/site:viewfullnames - able to see fullnames of other users<br /> #moodle/site:viewparticipants - able to view participants<br /> #moodle/site:viewreports - able to view site/course reports<br /> #moodle/site:trustcontent - ability to use trusttext feature and bypass cleaning in specific areas<br /> #moodle/site:uploadusers - ability to upload/update users from text file; moodle/role:assign capability is needed for course enrolling<br /> #moodle/blog:view - read blogs (usable in system or course context)<br /> #moodle/blog:create - write new blog posts (usable in system context only)<br /> #moodle/blog:manageofficialtags - create/delete official blog tags that others can use (usable in system context only)<br /> #moodle/blog:managepersonaltags - delete personal blog tags that others can use (usable in system context only) Note: users can always add own personal tags. This setting should be off for students by default.<br /> #moodle/blog:manageentries - edit/delete all blog entries (usable in system context only)<br /> #moodle/course:setcurrentsection - mark course section<br /> #moodle/course:create - create courses : 1)course/edit.php 2)course/category.php 3)course/index.php<br /> #moodle/course:delete - create courses : 1)course/category.php<br /> #moodle/course:update - update course settings<br /> #moodle/course:view - can use this to find participants<br /> #moodle/course:viewparticipants - allows a user to view participant list<br /> #moodle/course:viewscales - view scales (i.e. in a help window?) : 1)course/scales.php<br /> #moodle/course:manageactivities - adding/removing/editing activities and resources (don't think it makes any sense to split these)<br /> #moodle/course:managescales - add, delete, edit scales, move scales up and down : 1)blocks/block_admin.php 2)course/scales.php<br /> #moodle/course:managegroups - managing groups, add, edit, delete : 1)course/groups.php 2)course/group.php<br /> #moodle/course:managefiles - manage course files and folders<br /> #moodle/course:managequestions - manage course questions<br /> #moodle/course:managemetacourse - manage child courses in metacourse<br /> #moodle/course:reset - able to reset the course<br /> #moodle/course:useremail - Can use the enable/disable email stuff<br /> #moodle/course:visibility - hide/show courses : 1)course/category.php<br /> #moodle/course:viewhiddencourses - see hidden courses<br /> #moodle/course:activityvisibility - hide/show activities within a course<br /> #moodle/course:viewhiddenactivities - able to see activities that have been hidden<br /> #moodle/course:sectionvisibility - hide/show sections<br /> #moodle/course:viewhiddensections - view hidden sections<br /> #moodle/course:viewcoursegrades - views all grades in course<br /> #moodle/course:viewhiddenuserfields - view all hidden user fields<br /> #moodle/course:managegrades - manages grades settings in course<br /> #moodle/category:create - create category : 1)course/index.php<br /> #moodle/category:delete - delete category : 1)course/index.php<br /> #moodle/category:update - update category settings (sort and rename) this is currently an admin capability : 1)course/category.php<br /> #moodle/category:visibility - hide/show categories : 1)course/index.php<br /> #moodle/user:viewusergrades - view your own, or other user's grades (with specified context)<br /> #moodle/user:create - create user : 1) user/edit.php<br /> #moodle/user:delete - delete user : 1) admin/user.php<br /> #moodle/user:readuserblogs - read blog entries<br /> #moodle/user:update - update user settings : 1) user/edit.php<br /> #moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).<br /> #moodle/user:viewhiddendetails - view user details marked as &quot;hidden&quot;<br /> #moodle/calendar:manageownentries - create/edit/delete <br /> #moodle/calendar:manageentries - create/edit/delete<br /> #moodle/role:assign - assign roles to users<br /> #moodle/role:override - can override role capabilities (depending on context)<br /> #moodle/role:manage - create/edit/delete roles, set capability permissions for each role<br /> #moodle/role:unassignself - unassign yourself from your own roles<br /> #moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden<br /> #moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]<br /> #moodle/question:export - exports questions (course level?)<br /> #moodle/question:managecateory - add/delete/edit question categories (course level?)<br /> #moodle/question:manage - add/edit/delete a question (course level)<br /> <br /> ===User-level Capabilities===<br /> # moodle/user:readuserposts -read individual user posts on profile page (parent?)<br /> # moodle/user:readuserblogs -read individual user blogs on profile page (parent?)<br /> # moodle/user:viewuseractivitiesreport-read individual activity report on profile page (parent?)<br /> # moodle/user:editprofile - edit profile (normally used in CONTEXT_USERID and CONTEXT_SYSTEM)<br /> <br /> ===Module-level Capabilities===<br /> The capabilities are cached into a database table when a module is installed or updated. Whenever the capability definitions are updated, the module version number should be bumped up so that the database table can be updated.<br /> <br /> The naming convention for capabilities that are specific to modules and blocks is 'mod/mod_name:capability'. The part before the colon is the full path to the module in the Moodle code. The module capabilities are defined in mod/mod_name/db/access.php.<br /> <br /> #Assignment<br /> ##mod/assignment:view- reading the assignment description<br /> ##mod/assignment:submit - turn assignment in<br /> ##mod/assignment:grade - grading, viewing of list of submitted assignments<br /> #Chat<br /> ##mod/chat:chat - allows a user to participate in this chat<br /> ##mod/chat:readlog - allows a user to read past chat session logs<br /> ##mod/chat:deletelog - allows a user to delete past chat logs<br /> #Choice<br /> ##mod/choice:choose - make a choice<br /> ##mod/choice:readresponses - read all responses<br /> ##mod/choice:deleteresponses - deletes all responses<br /> ##mod/choice:downloadresponses - download responses<br /> #Database<br /> ##mod/data:viewentry - reads other people's entry<br /> ##mod/data:writeentry - add / edit and delete (own) entries<br /> ##mod/data:managetemplates - add, delete, edit fields and templates<br /> ##mod/data:manageentries - edit/delete all entries<br /> ##mod/data:comment - comment<br /> ##mod/data:managecomments - edit/delete all comments<br /> ##mod/data:rate - rate an entry<br /> ##mod/data:viewrating<br /> ##mod/data:approve - approves an entry<br /> ##mod/data:uploadentries - batch upload of entries<br /> #Exercise<br /> ##mod/exercise:assess<br /> #Forum<br /> ##mod/forum:viewdiscussion<br /> ##mod/forum:viewdiscussionsfromallgroups<br /> ##mod/forum:viewhiddentimedposts<br /> ##mod/forum:startdiscussion<br /> ##mod/forum:replypost<br /> ##mod/forum:viewrating<br /> ##mod/forum:viewanyrating<br /> ##mod/forum:rate<br /> ##mod/forum:createattachment<br /> ##mod/forum:deleteownpost<br /> ##mod/forum:deleteanypost<br /> ##mod/forum:splitdiscussions<br /> ##mod/forum:movediscussions<br /> ##mod/forum:editanypost<br /> ##mod/forum:viewqandawithoutposting<br /> ##mod/forum:viewsubscribers<br /> ##mod/forum:managesubscriptions<br /> ##mod/forum:throttlingapplies<br /> #Glossary<br /> ##mod/glossary:write - add entries<br /> ##mod/glossary:manageentries - add, edit, delete entries<br /> ##mod/glossary:managecategories - create, delete, edit categories<br /> ##mod/glossary:comment - comment on an entry<br /> ##mod/glossary:managecomments - edit, delete comments<br /> ##mod/glossary:import - import glossaries<br /> ##mod/glossary:export - export glossaries<br /> ##mod/glossary:approve - approve glossaries<br /> ##mod/glossary:rate - rates glossary<br /> ##mod/glossary:viewrating - view ratings<br /> #Hotpot<br /> ##mod/hotpot:attempt - attempt a hotpot<br /> ##mod/hotpot:viewreport - review and view reports<br /> ##mod/hotpot:grade - (grade? and) regrade<br /> ##mod/hotpot:deleteattempt - deletes attempts<br /> #Label<br /> ##none<br /> #Lams<br /> ##mod/lams:participate - original student<br /> ##mod/lams:manage - original teacher<br /> #Lesson<br /> ##mod/lesson:edit - add and edit pages<br /> ##mod/lesson:manage - view student attempts<br /> #Quiz<br /> ##mod/quiz:grade - comment, override grade, manual grade<br /> ##mod/quiz:preview - previews the quiz<br /> ##mod/quiz:viewreports - view quiz result reports<br /> ##mod/quiz:manage - add/delete/move (up or down) questions for a quiz<br /> ##mod/quiz:attempt - attempt the quiz--[[User:Tim Hunt|Tim Hunt]]<br /> #Resource<br /> #Scorm<br /> ##mod/scorm:viewgrades<br /> #Survey<br /> ##mod/survey:download - downloads survery result<br /> ##mod/survey:participate - participate/ do survey<br /> ##mod/survey:readresponses - read all user's responese<br /> #Wiki<br /> ##mod/wiki:participate - original student, meaning depends of type and course setting<br /> ##mod/wiki:manage - original teacher, manages assigned group; moodle/site:accessallgroups is needed to manage all groups <br /> ##(Waiting on new wiki)<br /> #Workshop<br /> ##mod/workshop:participate - original student, allows user to submit and assess<br /> ##mod/workshop:manage - original teacher, user can manage others<br /> ##(Waiting on new Workshop)<br /> <br /> ===Enrolment-level Capabilities===<br /> <br /> The naming convention for capabilities that are specific to enrolment is 'enrol/enrol_name:capability'. The enrolment capabilities are defined in enrol/enrol_name/db/access.php.<br /> <br /> #Authorize.net Payment Gateway <br /> ##enrol/authorize:managepayments - manage user payments, capture, void, refund, delete etc.<br /> <br /> ===Blocks===<br /> #activity_modules<br /> ##None<br /> #admin<br /> #admin_2<br /> #admin_bookmarks<br /> #blog_menu<br /> #blog_tags<br /> #calendar_month<br /> #calendar_upcoming<br /> #course_list<br /> #course_summary<br /> #glossary_random<br /> #html<br /> #loancalc<br /> #login<br /> #messages<br /> #news_items<br /> #online_users<br /> #participants<br /> #quiz_results<br /> #recent_activity<br /> #rss_client<br /> ##block/rss_client:createprivatefeeds<br /> ##block/rss_client:createsharedfeeds<br /> ##block/rss_client:manageownfeeds<br /> ##block/rss_client:manageanyfeeds<br /> #search<br /> #search_forums<br /> #section_links<br /> #site_main_menu<br /> #social_activities<br /> <br /> ===Questions===<br /> I am adding question categories here because they seem to have been forgotten in the whole scheme of things since having been removed from the quiz module itself. I've made a suggestion on how these could be handled in [http://www.moodle.org/bugs/bug.php?op=show&amp;bugid=6118&amp;pos= bug 6118].<br /> <br /> See [http://moodle.org/mod/forum/discuss.php?d=51143 this forum thread] for a discussion about the current problems wth publishing question categories.[[User:Tim Hunt|Tim Hunt]] 18:50, 8 August 2006 (WST)<br /> <br /> ==Programming Interface==<br /> <br /> Although the Roles system may look complicated at first glance, implementing it in Moodle code is fairly simple.<br /> <br /> * You need to define each capability once, so that Moodle can upgrade existing roles to take advantage of it. You do this in an access.php inside the db folder of any module (eg see mod/forum/db/access.php). The array contains entries like this (note the descriptions for the legacy roles which provides forward compatibility):<br /> 'mod/forum:viewforum' =&gt; array(<br /> 'captype' =&gt; 'read',<br /> 'contextlevel' =&gt; CONTEXT_MODULE,<br /> 'legacy' =&gt; array(<br /> 'guest' =&gt; CAP_PREVENT,<br /> 'student' =&gt; CAP_ALLOW,<br /> 'teacher' =&gt; CAP_ALLOW,<br /> 'editingteacher' =&gt; CAP_ALLOW,<br /> 'coursecreator' =&gt; CAP_ALLOW,<br /> 'admin' =&gt; CAP_ALLOW<br /> )<br /> ),<br /> * To load/change these capabilities you need to bump the module version. There's no need to provide changes or differences as Moodle will scan the whole array and sort it out.<br /> * On each page you need to find the context the user is working in, using the get_context_instance() function. For example, in the forum module:<br /> <br /> $context = get_context_instance(CONTEXT_MODULE, $cm-&gt;id);<br /> * or to at the course level:<br /> $context = get_context_instance(CONTEXT_COURSE, $id);<br /> * Then, whenever you want to check that the current user has rights to do something, call has_capability() like this:<br /> if (!has_capability('mod/forum:viewforum', $context)) {<br /> print_error('nopermissiontoviewforum');<br /> }<br /> * If you just want to assert a capability and then finish with an error message if it's not met (as we did above), then a shorter way it to use require_capability() like this:<br /> <br /> require_capability('mod/forum:viewforum', $context);<br /> <br /> * Note that there are extra parameters you can specify to get a custom error message, otherwise users get an automated &quot;No permissions&quot; message that lists the permission they were missing.<br /> <br /> <br /> As a result of the new Roles System, all calls to isadmin(), iscoursecreator, isteacheredit(), isteacher(), isstudent(), and isguest() will have to be replaced with calls to has_capability() or require_capability(). However, these functions will be retained for some backward compatibility with old code, using the legacy capabilities to try and work out what to do.<br /> <br /> ==Metacourses==<br /> <br /> The behaviour of metacourses in Moodle 1.7 changed slightly, in that where it used to just synch students from child courses to the parent course, it will now synch ALL roles. Teachers etc of the child courses will have the same role in the meta course. Technically metacourse synchronises all role assignments in CONTEXT_COURSE with its child courses; the only exception are users with moodle/course:managemetacourse capability, these users are synchronized only upwards, they are not unenrolled from metacourse when unenroling from child course or when removing the child from metacourse.<br /> <br /> In order to import/enrol other courses into metacoure you need to have moodle/course:managemetacourse capability. You can add manually only participants with moodle/course:managemetacourse, all other participants are automatically synced with child courses - if you try to manually enrol user without this capability error is displayed. Similar error is shown also when you try to manually unenrol participant from meta course while still being enrolled in child course.<br /> <br /> Sample setup:<br /> * metacourse manager has been assigned role with moodle/course:managemetacourse capability in system or course category context<br /> * students are enrolled in several child courses<br /> * teachers are enrolled in separate child course(s)<br /> <br /> ==Problem areas we are working on ==<br /> <br /> ===Student view===<br /> <br /> The &quot;Student view&quot; button has been removed completely.<br /> <br /> If there is time and a secure way can be found, it will be replaced by a menu to let the user assume a temporary role in the context of that course.<br /> <br /> ===Teacher forum===<br /> <br /> Teacher forums were always a curious exception to normal forums, as they were not part of a course as such, and were not backed up.<br /> <br /> We're taking the opportunity to rectify this. The upgrade converts teacher forums with content to normal forums in section 0 of the course, and ensures that only teachers can access them. If the teacher forum had not been used in the course then it's not converted and will just dissappear.<br /> <br /> ===Enrolment plugins===<br /> <br /> ====Process of logging in====<br /> <br /> # load_user_capability() is called to load all the capabilities<br /> # check_enrolment_plugins() is called at the top of load_user_capability() to check all the enrolment plugins.<br /> # For each active plugin:<br /> ##Check for setup_enrolments($user) and run it. This function will do all the processing needed to assign or unassign roles from the current user.<br /> # load_user_capability() continues and loads up all the roles<br /> # load_defaultuser_role() is called to add default site permissions (all users)<br /> <br /> ====Process of checking access to a course====<br /> <br /> require_login($course-&gt;id) is called by the script and has logic like this:<br /> <br /> # Is the user a guest at site level?<br /> ## Yes: Does the course allow guests?<br /> ### Yes: return true (and further capabilities are checked by the script)<br /> ### No: send the user to course/enrol.php for enrolment<br /> ## No: continue below<br /> <br /> # Does the user have moodle/course:view in that (course) context?<br /> ## Yes: then they can enter (and further capabilities are checked by the script)<br /> ## No: is guest access allowed on the course?<br /> ### Yes: assign temporary guest role to that user for that context (in session cache).<br /> ### No: send the user to course/enrol.php for enrolment.<br /> <br /> ====Process of enrolling====<br /> <br /> (more soon)<br /> <br /> ==Scenario brainstorming==<br /> <br /> This section is for brainstorming some example roles that we would like to support. Note some of these *may* not be possible in 1.7.<br /> <br /> ===Student===<br /> Obviously.<br /> <br /> ===Site Designers===<br /> Is there a role for people involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.<br /> <br /> ===Educational Authority Adviser===<br /> Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.<br /> <br /> ===Educational Inspector===<br /> Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.<br /> <br /> ===Second Marker / Moderator===<br /> A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.<br /> <br /> ===Peer observer of teaching===<br /> Many institutions encourage peer observation of teaching, to encourage reflection on practice. In online environments this will be similar to moderation or inspection. The peer observer would need to be able to experience the course &quot;as a student&quot;, but also to be able to view summaries of usage, transcripts of interactions (forums/surveys/polls etc), grades assigned (e.g. in assignments).<br /> <br /> ===External Examiner===<br /> Has all the rights of inspectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.<br /> <br /> ===Parent===<br /> A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.<br /> <br /> In Early Years (EY=3+4 yr olds) and Key Stage 1 (KS1=5+6 yr olds) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary. In Key Stage 2 (KS2=7-11 yr olds) parents would be more monitoring but may join in as well.<br /> <br /> In Key stages 3 (KS3=12-14 yr olds) and 4 (KS4=15+16 yr olds) this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.<br /> <br /> In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments. Also in all Key Satges there may be a home-school agreement which may be signed up to. Could this form part of a site policy system that incorporates a tickable list of activities the parent agrees to the child using (blogs/wikis/forums etc.)?<br /> <br /> Parent's evenings often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.<br /> <br /> In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face. <br /> <br /> The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.<br /> <br /> In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.<br /> <br /> Again in the UK, parents have their own independent right of access to a child's educational records. Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.<br /> <br /> There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.<br /> <br /> ===Manager===<br /> ''Please add text here...''<br /> <br /> ===Weekly Seminar Leader===<br /> ''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus &quot;Allow Quiz Authoring Role&quot; or &quot;Allow Assignment Authoring Role&quot; at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''<br /> <br /> ===Mentor/Mentee===<br /> ''Please add text here...''<br /> <br /> ===Community-Designed Rating Criteria===<br /> ''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''<br /> <br /> ===Visitor===<br /> <br /> This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant.<br /> <br /> ===Guest Speaker===<br /> <br /> This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have &quot;guest speakers&quot; who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.<br /> <br /> ===Former Student===<br /> This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?<br /> <br /> ===Alumnus=== An ALUMNUS should be able to search for all other ALUMNI of the school, interact with them and be enrolled in a seperate course - which is like a META course with all the content of his learning and interaction - as well as capabilities to be a part of this ALUMNI only course. All the teachers of courses during school years should automatically be a part of the ALUMNI course .. which means when an ALUMNUS is enrolled in a course, the original teachers of all his courses get enrolled ? --[[User:Anil Sharma|Anil Sharma]] 20:54, 15 July 2006 (WST)<br /> <br /> ===Librarian===<br /> <br /> Reference Librarians have an active role in most of the courses taught at some schools such as Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.<br /> <br /> In schools there is often a book review system. This may be covered by the lending system database but may not in which case a librarian may neeed to have a course area they can create a database template to handle the reviews in which case they may have a normal teacher style role? Off topic but course an integration with common schools database systems would be great.<br /> <br /> ===Teacher===<br /> <br /> Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity. <br /> <br /> I think that what is needed is a simple heirarchy of permissions and levels of granularity.<br /> <br /> I would take issue with &quot;teachers should have read access to other teacher's courses unless explicitly prohibited.&quot; This is a violation of the students' privacy as how they perform and what they do in one class isn't the business of another teacher. Moreover, in the real world a teacher wouldn't suddenly go sit in on a colleague's class without asking permission first. I would not have appreciated such an invasion of privacy as either a teacher or a student. It could be an option, but shouldn't be default.--[[User:N Hansen|N Hansen]] 19:54, 12 June 2006 (WST)<br /> <br /> ===Community Education Tutors/Trainers===<br /> Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.<br /> <br /> ===Secretary/Student Worker===<br /> <br /> We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.<br /> <br /> ===Teaching Assistant===<br /> <br /> Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker<br /> <br /> ===Student - FERPA rights===<br /> <br /> A student that has asserted their FERPA rights to non-disclosure. Typically includes not publishing their name<br /> in any public place. Could include this student only being seen with an &quot;alias&quot; within course spaces. Is this an attribute rather<br /> than a role?<br /> <br /> ===Help Desk===<br /> <br /> Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy<br /> of inheritance is needed, full access will be problematic with FERPA.<br /> <br /> ===Admin - Catgory based===<br /> <br /> Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add site-wide entries to the calendar etc.<br /> <br /> ===Process Roles===<br /> <br /> organising the learning process for a group you wish to have the choice to place students in differnt roles: examples of this are:<br /> * Give a student the role of forum-moderator with edit and chunk-rights<br /> * Give students different roles &amp; rights in a Webquest design (and change these roles next week<br /> * Give students different resources, depending of their roles in a rolegame/simulation<br /> * Give a student the rights to create the section content of next week (and only that week..)<br /> <br /> ==Things to finish for 1.7 Beta==<br /> '''18 Sept 2006'''<br /> <br /> #Remove core references to user_student, user_teacher, user_admin, user_coursecreator tables. [Yu]<br /> #Address function: isteacher, isadmin, isstudent [Yu]<br /> #Remove &quot;view&quot; capabilities from all modules unless required [Vy]<br /> #Remove all old references from remaining Blocks [Vy]<br /> #Metacourses [Skodak]<br /> #Add risks to GUI[Skodak]<br /> #Enrolment plugins [Martin and Alastair]<br /> #[[Stats_roles_1.7|Statistics]] [Penny]<br /> #Fix Loginas<br /> #Add category-level assigns [Yu]<br /> #[[Backup_roles_1.7|Backups]] [Eloy?]<br /> <br /> ===Proposal for interface enhancement===<br /> Martin asked some questions, here are my answers. The sketches below are not worked out proposals. Their task is to visualize the idea. The exact colours and functionality may be defined after possible agreement about the proposals. The Green, orange and red columns support the meaning of the options from &quot;allow&quot; to &quot;prohibit&quot; (If you may want to see larger images please click onto the image or the &quot;Enlarge&quot; icon below the image.)<br /> <br /> The list of possible settings is very long and '' &quot;... the problem is not to overwhelm people with information&quot; ''. <br /> <br /> [[Image:01_moodle_define_roles_structured.png|thumb=01_moodle_define_roles_structured_pre.png]]<br /> <br /> 1) One proposal is to use colour to structure the sections and the columns. Picture 1 shows that the user can keep a much better overview when the list is divided into meaningful different coloured columns and clear sections.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:02_moodle_define_roles_collapsed.png|thumb=02_moodle_define_roles_collapsed_pre.png]]<br /> <br /> 2) A second proposal is to reduce the amount of information the user is shown at the same time. The YUI interface library offers great support to show/hide sections of the page by clicking on specific elements. <br /> <br /> For example click on an icon beside the sub heading &quot;Course categories&quot; and show/hide all table rows with the CLASS &quot;course-category&quot;.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:03_moodle_define_roles_tooltip.png|thumb=03_moodle_define_roles_tooltip_pre.png]]<br /> <br /> 3) '' &quot;The main problem is the last column for risk ... we were thinking of putting little icons in there ...&quot; ''<br /> Icons are good when they tell the user more about possible actions/meanings then the letters. I am not sure if this is the case here. For both - icons or letters - the YUI tool-tip function would be able to give the user valuable information about the meaning.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> ==See also==<br /> <br /> *[[Hardening new Roles system]]<br /> *[[Roles and modules]]<br /> *Using Moodle course:<br /> **[http://moodle.org/mod/forum/view.php?f=941 Roles and Capabilities forum]<br /> **Key discussions at Using Moodle forums:<br /> ***[http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture]<br /> ***[http://moodle.org/mod/forum/discuss.php?d=56302#256313 An example of admin roles as set in the database]<br /> <br /> [[Category:Roles]]<br /> [[Category:Roles]]<br /> <br /> [[fr:Developpement:Roles]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Latest_release_notes&diff=25242 2007-09-19T04:06:24Z

<p>Martinlanghoff: Notes</p> <hr /> <div>{{About Moodle}}<br /> <br /> ==Moodle 1.9 Beta==<br /> <br /> Released: 14th August 2007<br /> <br /> This is a DEVELOPMENT RELEASE made available for wider testing by the community in preparation for a polished release of 1.9 in the coming weeks. It should not be used for production sites unless you are prepared to report the bugs you find in the [http://tracker.moodle.org Moodle Tracker], hopefully with your patches attached. :-)<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10190 the full list of fixed issues in 1.9 so far].<br /> <br /> ===Headline features===<br /> <br /> * [[Development:Grades|Gradebook]] - Moodle.com (funded by Open University)<br /> :: Completely rewritten from scratch for speed and flexibility. The new gradebook consists of plugins for reports, imports and exports. There are a number of standard reports which are useful for graders, students etc. The grader report allows you to treat the gradebook much more like a spreadsheet with manual editing, calculations, aggregations, weighting, locking, hiding, textual notes and so on.<br /> * [[Development:Outcomes|Outcomes]] - Moodle.com<br /> :: You can also now develop a list of expected outcomes (competencies) and connect these to courses and activities. You can even grade against multiple outcomes at once (ie Rubrics).<br /> * [[Development:Events|Events API]] - Moodle.com<br /> ::The new Events API provides a way for any code to &quot;hook&quot; into events in a clean, loosely coupled way. It's the foundation of the new gradebook. A lot of events in Moodle (such as adding a user or a course) now trigger events that developers can hook into.<br /> * [[Tags]] - Luiz Cruz ([[Student_projects/Social_Networking_features|Google SOC Social Networking project]])<br /> :: allows users to describe their own interests in terms of tags, which creates interest pages around those tags, bringing information together from a variety of sources.<br /> * [[Question_Engine_Changes_in_Moodle_1.9|Improved question bank]] - Jamie Pratt funded by [http://www.fun.ac.jp/en/ Future University Hakodate].<br /> ::Allows questions to be shared by the whole site, a course category, a singe course, or be kept private to a single module. More control over who can do what to each question. Improved file management for files linked to by questions.<br /> * [[Notes]] - <br /> :: Detailed notes can be kept about individual users (for example teachers might want to keep and share notes about students in their class).<br /> * New Custom Corners theme - Urs Hunkler<br /> :: Beautiful and curvy (in all browsers).<br /> <br /> ===Other major improvements===<br /> <br /> * Groups and Groupings<br /> :: New support for groupings (groups of groups) which was added briefly and then removed from 1.8.x.<br /> * New theme settings<br /> ** Category themes - can now set the theme for a category which will apply to all sub-categories and courses<br /> ** Theme order - new setting ''$CFG-&gt;themeorder'' which sets the priority of the themes from highest to lowest.<br /> <br /> ===Module improvements===<br /> <br /> * Quiz/Question improvements:<br /> ** A quiz can now [[Quiz submission email notification|send emails when an attempt is finished]] - a confirmation to the student, a notification to all teachers, or both. (Implemented by Graham Miller of [http://www.webenhanced.com.au/ Web Enhanced Solutions]).<br /> ** Third party question types can now implement Moodle XML and other import and export formats (Implemented by Howard Miller).<br /> ** Gift Import/Export format can now handle Essay and Description question types.<br /> ** Some slight improvements to quiz layout. See [http://tracker.moodle.org/browse/MDL-10374 MDL-10374] for details. Theme designers please note.<br /> ** Multiple choice questions now show the feedback for all the options to students on the review page after the attempt is over.<br /> <br /> ''Developers please add news here!''<br /> <br /> ===Notes===<br /> <br /> * In the new accesslib there is a subtle difference in how we resolve conflicts between 'allow' and 'prevent' capabilities. See [[Development:Roles#Capability-locality_changes_in_v1.9]]<br /> <br /> ==Moodle 1.8.2==<br /> <br /> Released: 8th July 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10220&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.2].<br /> <br /> ===Highlights===<br /> * Two XSS security vulnerabilities (one reported in the wild) were fixed.<br /> <br /> <br /> ==Moodle 1.8.1==<br /> <br /> Released: 14th June 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10213&amp;styleName=Html&amp;projectId=10011 the full list of fixed issues in 1.8.1].<br /> <br /> ===Highlights===<br /> * The groups implementation has been cleaned up somewhat from the 1.8 release. The '''groupings''' GUI that appeared in 1.8 has been removed, because groupings are not complete and should not be used yet. Moodle 1.8 sites that have created groupings should upgrade to 1.8.1 to have groupings reset ... otherwise there could be problem when upgrading to the real groupings in 1.9 or later.<br /> <br /> ==Moodle 1.8==<br /> <br /> Released: 31st March 2007<br /> <br /> Here is [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10130 the full list of fixed issues in 1.8].<br /> <br /> ===Headline features===<br /> <br /> * [[Accessibility]] - Moodle.com <br /> :: The Moodle interface is now compliant with XHTML Strict 1.0 and major accessibility standards.<br /> * [[Moodle Network]] - Catalyst, Richard Wyles<br /> :: We can now set up peer Moodle installations allowing users to roam from one site to another, using comprehensive SSO and transparent remote enrolments. Administrators at the originating Moodle install can see logs of remote activity. You can also run your Moodle in &quot;Hub&quot; mode where any Moodle install can connect and users roam across.<br /> * [[Web Services API]] - Catalyst, Richard Wyles<br /> :: The Moodle Network code includes an XML-RPC call dispatcher that can expose the WHOLE Moodle API to trusted hosts. We will building on this in further versions but you can start using it now if you need to.<br /> * [[Development:lib/formslib.php|Moodle forms library]] - Moodle.com <br /> :: Majority of forms now use a single API for defining forms consistently and collecting data safely without using any HTML at all.<br /> * [[Multi Authentication]] - Iñaki Arenaza / Catalyst / Moodle.com<br /> :: It is now easier to configure multiple sources of authentication at once. WARNING: the format for authentication plugins has changed, so custom plugins may be broken, however it's very easy to convert old code to the new format. More details can be found in /auth/README.txt.<br /> * [[Development:Customisable user profiles|Customisable User Profiles]] - Pukunui Technology<br /> ::Allow new arbitrary fields to be added to the user profile, with more control over what fields appear on what signup and profile editing screens.<br /> * Groups refactor - OU / Moodle.com<br /> ::Groups code has been reorganised to make it more flexible for the future (see 1.9). <br /> * [http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&amp;requestId=10221 Roles improvements] - Moodle.com<br /> :: In addition to many Roles fixes and refinements, Moodle 1.8 has separated the SYSTEM context from the SITE context (which makes it more like 1.6 used to work). The SITE context is the &quot;front page course&quot; and its activities. This should make it easier for admins to set up permissions. Login as and switching of roles was rewritten. Administrators can view recommended permission settings of legacy roles and may reset legacy roles to defaults.<br /> * [http://tracker.moodle.org/browse/MDL-7993 Support for ODS export] - Moodle.com<br /> ::Open Document Format should solve majority of current problems with exports into proprietary Excel format. You may need to install special import plugin if you are using MS Office.<br /> <br /> ===Known problems===<br /> * CAS auth not working<br /> <br /> ===Module improvements===<br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :: Payment managers can obtain an authorization code over phone from customer's bank if the credit card of the user cannot be captured on the internet directly.<br /> <br /> ''Developers please add news here!''<br /> <br /> ===See also===<br /> *[[Upgrading to Moodle 1.8]]<br /> <br /> ==Moodle 1.7.2==<br /> <br /> 30th March, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10174 This page shows issues resolved in this version]<br /> <br /> ===Security===<br /> <br /> * Unintended logouts are now prevented - sesskey added to logout.php script<br /> * Fixed problem with visible posts in user profile when &quot;forceloginforprofiles&quot; disabled<br /> * Fixed visibility of site blog entries<br /> * Corrected wrong includes in lams<br /> * XSS injection in SCORM 1.2 reports<br /> * Fixed old problem with approvals in Data module, edited entries were approved automatically<br /> * Fixed escaping in shell commands (Win32 platform only)<br /> * Fixed visibility of blog drafts<br /> * Rewritten parameter handling in repository plugin<br /> * Fixed XSS in login block<br /> <br /> ==Moodle 1.7.1==<br /> <br /> 17th January, 2007<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?projectId=10011&amp;styleName=Html&amp;version=10151 This page shows details about issues resolved in this version]<br /> <br /> ==Moodle 1.7==<br /> <br /> 7th November, 2006<br /> <br /> [http://tracker.moodle.org/secure/ReleaseNote.jspa?version=10120&amp;styleName=Html&amp;projectId=10011&amp;Create=Create This page shows details about issues resolved in this version] <br /> <br /> ===Headline features=== <br /> <br /> * [[Roles]] <br /> :: Permissions based on fine-grained capabilities allow all kinds of roles to be created and assigned in all contexts around Moodle. This creates a great deal more flexibility in the permissions that you can grant to people. <br /> * [[Development:XMLDB Documentation|XML Database Schema]] <br /> :: added support for MS-SQL and Oracle with more databases to come. Developers now have just one XML file to edit when changing the database structure, and there is even a very funky editor for this file built-in to Moodle <br /> * New Admin interface <br /> :: Completely new admin interface, with accessible design and cool features to make access to settings fast and easy. <br /> * [[Unit tests|Unit testing framework]] <br /> :: Making it easier for developers to write test code, which should ultimately lead to a more reliable Moodle. <br /> * [[AJAX]] Course editing (STILL UNSTABLE IN 1.7 RELEASE AND OFF BY DEFAULT, USE WITH CAUTION!) <br /> :: The Topics and Weekly course formats now feature AJAX editing which means you can drag drop blocks, activities and sections (weeks/topics) and it all happens instantly. No more page reloading!<br /> <br /> ===Module improvements=== <br /> <br /> * Improvements to the [[Assignment module]] <br /> **New type Advanced uploading of files <br /> <br /> * Improvements to the [[Database module]] <br /> **Template/Field settings can now be saved as Presets and shared across a site. <br /> **Presets are just zip files, and can also be shared between sites. <br /> **Moodle 1.7 comes with one sample preset (an Image Gallery) with more to come. <br /> **New latitude/longitude data type <br /> <br /> * Improvements to the [[Lesson module]] <br /> **Now has a more unified view of lesson screens. <br /> **Teacher editing: <br /> ***Collapsed view has a nicer format, displays more information regarding each page and allows the creation of new pages. <br /> ***Editing is now speedier by replacing 3 second redirect delays with a notification system. <br /> **New feature: display default feedback. <br /> ***Default is '''On''' so previous lessons behave as before. <br /> ***Description: if no ''response'' is entered for a question answer and this setting is turned '''Off''', then the user skips the feedback page. <br /> **Graceful degrade of JavaScript. <br /> **Several bug fixes. <br /> <br /> * Improvements to the [[Quiz module]] <br /> :* The teacher can configure comments that are displayed to the student at the end of their attempt, with the comment displayed depending on the student's score. <br /> <br /> * Improvements to some core question types <br /> :* All question types can now have some general feedback. This is displayed to all students after they have finished the question (depending on the quiz settings) and does not depend on what response the student gave. Use this to tell the student what the question was about, or link them to more information about the topic it covers. <br /> :* [[Matching question type|Matching]] questions can have extra wrong answers, and work when two questions have the same answer. <br /> :* [[Multiple Choice question type|Multiple Choice]] questions can have feedback for the whole question, as well as specific answers. This is particularly useful for multiple-response questions. <br /> :* [[Numerical question type|Numerical]] questions can have different answers with different precisions and scores. (Previously this was only supported via GIFT import. Now you can edit questions like this.) <br /> <br /> * Improvements to the [[Wiki module]] <br /> :* While editing a wiki page it is now locked so that others cannot try to change it at the same time. Teachers can override the lock. <br /> :* Minor bugfixes (mostly to fix problems that occured when using Postgres database). <br /> <br /> ===Enrolment plugin improvements=== <br /> <br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :*Accepts 'Electronic Checks (ACH)'. After a user approving echeck, an admin who has upload csv capacity must import a CSV file to get the user enrolled in the Payment Management page. <br /> :*Autoconfigures credit card and echeck types if the merchant does not accept some types of them.<br /> <br /> == See also ==<br /> *[[Old releases|Old release notes]]<br /> <br /> [[es:Notas de versiones]]<br /> [[fr:Notes de mise à jour]]<br /> [[pt:Versões do Moodle]]<br /> [[ru:Примечания к версиям]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Roles&diff=3162 2007-09-19T04:04:24Z

<p>Martinlanghoff: /* The new roles and capability system */</p> <hr /> <div>{{Moodle 1.7}}<br /> '''Roles and permissions''' is in Moodle 1.7 onwards.<br /> <br /> ==Definitions==<br /> <br /> A role is an identifier of the user's status in some context. For example: Teacher, Student and Forum moderator are examples of roles.<br /> <br /> A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example, ''mod/forum:replypost'' is a capability.<br /> <br /> A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.<br /> <br /> A context is a &quot;space&quot; in the Moodle, such as courses, activity modules, blocks etc.<br /> <br /> ==The existing system==<br /> <br /> In versions prior to v1.7, Moodle uses a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can perform are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.<br /> <br /> ==The new roles and capability system==<br /> <br /> With v1.7 and greater, Moodle introduces a roles and capabilities system.<br /> <br /> Role has two primary functions:<br /> # define list of permissions - role definition is global for all contexts, but can be changed by local context overrides<br /> # replace old course enrolments - role assignment in course context is simitar to the old enrolment process<br /> <br /> The new system will allow authorized users to define an arbitrary number of roles (eg a teacher) <br /> <br /> A role consists of a list of permissions for different possible actions within Moodle (eg delete discussions, add activities etc)<br /> <br /> Roles can be applied to users in a context (eg assign Fred as a teacher in a particular course)<br /> <br /> Here are the possible contexts, listed from the most general to the most specific. <br /> <br /> #CONTEXT_SYSTEM -- the whole site<br /> #CONTEXT_PERSONAL -- yourself<br /> #CONTEXT_USER -- another user<br /> #CONTEXT_COURSECAT -- a course category<br /> #CONTEXT_COURSE -- a course<br /> '''#CONTEXT_GROUP -- a group<br /> #CONTEXT_MODULE -- an activity module<br /> #CONTEXT_BLOCK -- a block<br /> <br /> [[Image:Moodle-contexts-1.8.png|right|thumb|A diagram of the contexts in Moodle 1.8, based on the [[Talk:Roles_and_capabilities|text diagram by Martin Dougiamas]]. Click on the diagram to see a more detailed view of it.]]<br /> <br /> An authorized user will be able to assign an arbitrary number of roles to each user in any context.<br /> <br /> Capabilities can have the following permissions:<br /> <br /> #CAP_INHERIT<br /> #CAP_ALLOW<br /> #CAP_PREVENT<br /> #CAP_PROHIBIT<br /> <br /> If no permission is defined, then the capability permission is inherited from a context that is more general than the current context. If we define different permission values for the same capability in different contexts, we say that we are overriding the capability in the more specific context.<br /> <br /> Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by enforcing the rule that the capability defined for a more specific context will win, unless a prohibit is encountered in a less specific context.<br /> <br /> For example, Mark has a student role at course level, which allows him to write into a wiki. But Mark also got assigned a Visitor role at a module context level (for a particular wiki) which prevents him from writing to the wiki (read only). Therefore, for this particular wiki, Mark will not be able to write to the wiki since the more specific context wins.<br /> <br /> If we set a PROHIBIT on a capability, it means that the capability cannot be overridden and will ALWAYS have a permission of prevent (deny). Prohibit always wins. For example, Jeff has a naughty student role that prohibits him from postings in any forums (for the whole site), but he's also assigned a facilitator role in &quot;Science forum&quot; in the course Science and Math 101. Since prohibit always wins, Jeff is unable to post in &quot;Science forum&quot;.<br /> <br /> Allow and prevent will cancel each other out if set for the same capability at the same context level. If this happens, we refer to the previous context level to determine the permission for the capability.<br /> <br /> This may sound more complex than it really is in practice. The upshot is that the system can be flexible enough to allow pretty much any combination of permissions.<br /> <br /> ===Capability-locality changes in v1.9===<br /> <br /> When resolving conflicts between &quot;allow&quot; and &quot;prevent&quot; in v1.7 and v1.8 the locality of the capability is taken into account, although with less weight than the locality of the role assignment. In v1.9 the process has been simplified, we consider locality of the role assignment when dealing with allow/prevent conflicts, but ignore where the capability has been defined (as long as it applies to the context).<br /> <br /> For example - for the situation where there is<br /> <br /> * two roles assigned to one user in a context (eg student role and teacher role)<br /> * one override on one of those roles ( eg student role), at the same context<br /> <br /> then<br /> <br /> * '''1.7/1.8''' The override used to ''always'' win over the settings from the combined roles.<br /> <br /> * '''1.9''' The override is combined with the student role first. and then the roles are combined. This is more logical, as the override is acting like a modification to the student role.<br /> <br /> ==Upgrading from 1.6==<br /> <br /> A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the existing capabilities will be automatically retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, mirroring what we have in 1.6. With no modifications, Moodle will operate exactly the same before and after the upgrade.<br /> <br /> ===Admins===<br /> <br /> Admin users will be assigned the default legacy admin role in the system (site) context<br /> <br /> ===Course Creators===<br /> <br /> Course Creators will be assigned the default legacy course creator role in the system (site) context<br /> <br /> ===Teachers===<br /> <br /> Users who were teachers will be assigned the default legacy teacher role (or non-editing teacher role) in all courses they were teacher.<br /> <br /> ===Students===<br /> <br /> Users who were students will be assigned the default student role in all courses they were student.<br /> <br /> ===Guests===<br /> <br /> There will still be a single guest user with no default role at site level. For each course that allows guest access, the guest role will be assigned to the guest user for that course context. The guest control for the course will be modified from three to two options (guests always need to enter enrolment key - on/off). This setting is checked as now to force guests to enter key.<br /> <br /> ==Capabilities==<br /> <br /> This will be a comprehensive list of capabilities (it's not complete yet). It is important that capability names are unique.<br /> <br /> ===Core-level Capabilities===<br /> <br /> Moodle core capability names start with 'moodle/'. The next word indicates what type of core capability it is, and the last word is the actual capability itself. The capabilities for the Moodle core are defined in lib/db/access.php<br /> <br /> #moodle/legacy:guest - legacy capabilities are used to transition existing users to the new roles system during the upgrade to Moodle 1.7<br /> #moodle/legacy:student<br /> #moodle/legacy:teacher<br /> #moodle/legacy:editingteacher<br /> #moodle/legacy:coursecreator<br /> #moodle/legacy:admin<br /> #moodle/site:doanything - special capability, meant for admins, if is set, overrides all other capability settings<br /> #moodle/site:config - applicable in admin/index.php and config.php (might break down later) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()<br /> #moodle/site:readallmessages - reads all messages and history<br /> #moodle/site:approvecourse - approves a pending course<br /> #moodle/site:manageblocks - adding/removing/editing blocks (site, course contexts only for now) : 1)_add_edit_controls moodleblock.class.php <br /> #moodle/site:backup - can create a course backup : 1)course/category.php 2)block_admin.php<br /> #moodle/site:restore - can restore into this context : 1)course/category.php 2)block_admin.php<br /> #moodle/site:import - can import other courses into this context : 1)block_admin.php<br /> #moodle/site:accessallgroups - able to access all groups irrespective of what group the user is in<br /> #moodle/site:accessdb - directly accessing db (phpmyadmin)<br /> #moodle/site:viewfullnames - able to see fullnames of other users<br /> #moodle/site:viewparticipants - able to view participants<br /> #moodle/site:viewreports - able to view site/course reports<br /> #moodle/site:trustcontent - ability to use trusttext feature and bypass cleaning in specific areas<br /> #moodle/site:uploadusers - ability to upload/update users from text file; moodle/role:assign capability is needed for course enrolling<br /> #moodle/blog:view - read blogs (usable in system or course context)<br /> #moodle/blog:create - write new blog posts (usable in system context only)<br /> #moodle/blog:manageofficialtags - create/delete official blog tags that others can use (usable in system context only)<br /> #moodle/blog:managepersonaltags - delete personal blog tags that others can use (usable in system context only) Note: users can always add own personal tags. This setting should be off for students by default.<br /> #moodle/blog:manageentries - edit/delete all blog entries (usable in system context only)<br /> #moodle/course:setcurrentsection - mark course section<br /> #moodle/course:create - create courses : 1)course/edit.php 2)course/category.php 3)course/index.php<br /> #moodle/course:delete - create courses : 1)course/category.php<br /> #moodle/course:update - update course settings<br /> #moodle/course:view - can use this to find participants<br /> #moodle/course:viewparticipants - allows a user to view participant list<br /> #moodle/course:viewscales - view scales (i.e. in a help window?) : 1)course/scales.php<br /> #moodle/course:manageactivities - adding/removing/editing activities and resources (don't think it makes any sense to split these)<br /> #moodle/course:managescales - add, delete, edit scales, move scales up and down : 1)blocks/block_admin.php 2)course/scales.php<br /> #moodle/course:managegroups - managing groups, add, edit, delete : 1)course/groups.php 2)course/group.php<br /> #moodle/course:managefiles - manage course files and folders<br /> #moodle/course:managequestions - manage course questions<br /> #moodle/course:managemetacourse - manage child courses in metacourse<br /> #moodle/course:reset - able to reset the course<br /> #moodle/course:useremail - Can use the enable/disable email stuff<br /> #moodle/course:visibility - hide/show courses : 1)course/category.php<br /> #moodle/course:viewhiddencourses - see hidden courses<br /> #moodle/course:activityvisibility - hide/show activities within a course<br /> #moodle/course:viewhiddenactivities - able to see activities that have been hidden<br /> #moodle/course:sectionvisibility - hide/show sections<br /> #moodle/course:viewhiddensections - view hidden sections<br /> #moodle/course:viewcoursegrades - views all grades in course<br /> #moodle/course:viewhiddenuserfields - view all hidden user fields<br /> #moodle/course:managegrades - manages grades settings in course<br /> #moodle/category:create - create category : 1)course/index.php<br /> #moodle/category:delete - delete category : 1)course/index.php<br /> #moodle/category:update - update category settings (sort and rename) this is currently an admin capability : 1)course/category.php<br /> #moodle/category:visibility - hide/show categories : 1)course/index.php<br /> #moodle/user:viewusergrades - view your own, or other user's grades (with specified context)<br /> #moodle/user:create - create user : 1) user/edit.php<br /> #moodle/user:delete - delete user : 1) admin/user.php<br /> #moodle/user:readuserblogs - read blog entries<br /> #moodle/user:update - update user settings : 1) user/edit.php<br /> #moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo).<br /> #moodle/user:viewhiddendetails - view user details marked as &quot;hidden&quot;<br /> #moodle/calendar:manageownentries - create/edit/delete <br /> #moodle/calendar:manageentries - create/edit/delete<br /> #moodle/role:assign - assign roles to users<br /> #moodle/role:override - can override role capabilities (depending on context)<br /> #moodle/role:manage - create/edit/delete roles, set capability permissions for each role<br /> #moodle/role:unassignself - unassign yourself from your own roles<br /> #moodle/role:viewhiddenassigns - view role assignments that have been marked as hidden<br /> #moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--[[User:Tim Hunt|Tim Hunt]]<br /> #moodle/question:export - exports questions (course level?)<br /> #moodle/question:managecateory - add/delete/edit question categories (course level?)<br /> #moodle/question:manage - add/edit/delete a question (course level)<br /> <br /> ===User-level Capabilities===<br /> # moodle/user:readuserposts -read individual user posts on profile page (parent?)<br /> # moodle/user:readuserblogs -read individual user blogs on profile page (parent?)<br /> # moodle/user:viewuseractivitiesreport-read individual activity report on profile page (parent?)<br /> # moodle/user:editprofile - edit profile (normally used in CONTEXT_USERID and CONTEXT_SYSTEM)<br /> <br /> ===Module-level Capabilities===<br /> The capabilities are cached into a database table when a module is installed or updated. Whenever the capability definitions are updated, the module version number should be bumped up so that the database table can be updated.<br /> <br /> The naming convention for capabilities that are specific to modules and blocks is 'mod/mod_name:capability'. The part before the colon is the full path to the module in the Moodle code. The module capabilities are defined in mod/mod_name/db/access.php.<br /> <br /> #Assignment<br /> ##mod/assignment:view- reading the assignment description<br /> ##mod/assignment:submit - turn assignment in<br /> ##mod/assignment:grade - grading, viewing of list of submitted assignments<br /> #Chat<br /> ##mod/chat:chat - allows a user to participate in this chat<br /> ##mod/chat:readlog - allows a user to read past chat session logs<br /> ##mod/chat:deletelog - allows a user to delete past chat logs<br /> #Choice<br /> ##mod/choice:choose - make a choice<br /> ##mod/choice:readresponses - read all responses<br /> ##mod/choice:deleteresponses - deletes all responses<br /> ##mod/choice:downloadresponses - download responses<br /> #Database<br /> ##mod/data:viewentry - reads other people's entry<br /> ##mod/data:writeentry - add / edit and delete (own) entries<br /> ##mod/data:managetemplates - add, delete, edit fields and templates<br /> ##mod/data:manageentries - edit/delete all entries<br /> ##mod/data:comment - comment<br /> ##mod/data:managecomments - edit/delete all comments<br /> ##mod/data:rate - rate an entry<br /> ##mod/data:viewrating<br /> ##mod/data:approve - approves an entry<br /> ##mod/data:uploadentries - batch upload of entries<br /> #Exercise<br /> ##mod/exercise:assess<br /> #Forum<br /> ##mod/forum:viewdiscussion<br /> ##mod/forum:viewdiscussionsfromallgroups<br /> ##mod/forum:viewhiddentimedposts<br /> ##mod/forum:startdiscussion<br /> ##mod/forum:replypost<br /> ##mod/forum:viewrating<br /> ##mod/forum:viewanyrating<br /> ##mod/forum:rate<br /> ##mod/forum:createattachment<br /> ##mod/forum:deleteownpost<br /> ##mod/forum:deleteanypost<br /> ##mod/forum:splitdiscussions<br /> ##mod/forum:movediscussions<br /> ##mod/forum:editanypost<br /> ##mod/forum:viewqandawithoutposting<br /> ##mod/forum:viewsubscribers<br /> ##mod/forum:managesubscriptions<br /> ##mod/forum:throttlingapplies<br /> #Glossary<br /> ##mod/glossary:write - add entries<br /> ##mod/glossary:manageentries - add, edit, delete entries<br /> ##mod/glossary:managecategories - create, delete, edit categories<br /> ##mod/glossary:comment - comment on an entry<br /> ##mod/glossary:managecomments - edit, delete comments<br /> ##mod/glossary:import - import glossaries<br /> ##mod/glossary:export - export glossaries<br /> ##mod/glossary:approve - approve glossaries<br /> ##mod/glossary:rate - rates glossary<br /> ##mod/glossary:viewrating - view ratings<br /> #Hotpot<br /> ##mod/hotpot:attempt - attempt a hotpot<br /> ##mod/hotpot:viewreport - review and view reports<br /> ##mod/hotpot:grade - (grade? and) regrade<br /> ##mod/hotpot:deleteattempt - deletes attempts<br /> #Label<br /> ##none<br /> #Lams<br /> ##mod/lams:participate - original student<br /> ##mod/lams:manage - original teacher<br /> #Lesson<br /> ##mod/lesson:edit - add and edit pages<br /> ##mod/lesson:manage - view student attempts<br /> #Quiz<br /> ##mod/quiz:grade - comment, override grade, manual grade<br /> ##mod/quiz:preview - previews the quiz<br /> ##mod/quiz:viewreports - view quiz result reports<br /> ##mod/quiz:manage - add/delete/move (up or down) questions for a quiz<br /> ##mod/quiz:attempt - attempt the quiz--[[User:Tim Hunt|Tim Hunt]]<br /> #Resource<br /> #Scorm<br /> ##mod/scorm:viewgrades<br /> #Survey<br /> ##mod/survey:download - downloads survery result<br /> ##mod/survey:participate - participate/ do survey<br /> ##mod/survey:readresponses - read all user's responese<br /> #Wiki<br /> ##mod/wiki:participate - original student, meaning depends of type and course setting<br /> ##mod/wiki:manage - original teacher, manages assigned group; moodle/site:accessallgroups is needed to manage all groups <br /> ##(Waiting on new wiki)<br /> #Workshop<br /> ##mod/workshop:participate - original student, allows user to submit and assess<br /> ##mod/workshop:manage - original teacher, user can manage others<br /> ##(Waiting on new Workshop)<br /> <br /> ===Enrolment-level Capabilities===<br /> <br /> The naming convention for capabilities that are specific to enrolment is 'enrol/enrol_name:capability'. The enrolment capabilities are defined in enrol/enrol_name/db/access.php.<br /> <br /> #Authorize.net Payment Gateway <br /> ##enrol/authorize:managepayments - manage user payments, capture, void, refund, delete etc.<br /> <br /> ===Blocks===<br /> #activity_modules<br /> ##None<br /> #admin<br /> #admin_2<br /> #admin_bookmarks<br /> #blog_menu<br /> #blog_tags<br /> #calendar_month<br /> #calendar_upcoming<br /> #course_list<br /> #course_summary<br /> #glossary_random<br /> #html<br /> #loancalc<br /> #login<br /> #messages<br /> #news_items<br /> #online_users<br /> #participants<br /> #quiz_results<br /> #recent_activity<br /> #rss_client<br /> ##block/rss_client:createprivatefeeds<br /> ##block/rss_client:createsharedfeeds<br /> ##block/rss_client:manageownfeeds<br /> ##block/rss_client:manageanyfeeds<br /> #search<br /> #search_forums<br /> #section_links<br /> #site_main_menu<br /> #social_activities<br /> <br /> ===Questions===<br /> I am adding question categories here because they seem to have been forgotten in the whole scheme of things since having been removed from the quiz module itself. I've made a suggestion on how these could be handled in [http://www.moodle.org/bugs/bug.php?op=show&amp;bugid=6118&amp;pos= bug 6118].<br /> <br /> See [http://moodle.org/mod/forum/discuss.php?d=51143 this forum thread] for a discussion about the current problems wth publishing question categories.[[User:Tim Hunt|Tim Hunt]] 18:50, 8 August 2006 (WST)<br /> <br /> ==Programming Interface==<br /> <br /> Although the Roles system may look complicated at first glance, implementing it in Moodle code is fairly simple.<br /> <br /> * You need to define each capability once, so that Moodle can upgrade existing roles to take advantage of it. You do this in an access.php inside the db folder of any module (eg see mod/forum/db/access.php). The array contains entries like this (note the descriptions for the legacy roles which provides forward compatibility):<br /> 'mod/forum:viewforum' =&gt; array(<br /> 'captype' =&gt; 'read',<br /> 'contextlevel' =&gt; CONTEXT_MODULE,<br /> 'legacy' =&gt; array(<br /> 'guest' =&gt; CAP_PREVENT,<br /> 'student' =&gt; CAP_ALLOW,<br /> 'teacher' =&gt; CAP_ALLOW,<br /> 'editingteacher' =&gt; CAP_ALLOW,<br /> 'coursecreator' =&gt; CAP_ALLOW,<br /> 'admin' =&gt; CAP_ALLOW<br /> )<br /> ),<br /> * To load/change these capabilities you need to bump the module version. There's no need to provide changes or differences as Moodle will scan the whole array and sort it out.<br /> * On each page you need to find the context the user is working in, using the get_context_instance() function. For example, in the forum module:<br /> <br /> $context = get_context_instance(CONTEXT_MODULE, $cm-&gt;id);<br /> * or to at the course level:<br /> $context = get_context_instance(CONTEXT_COURSE, $id);<br /> * Then, whenever you want to check that the current user has rights to do something, call has_capability() like this:<br /> if (!has_capability('mod/forum:viewforum', $context)) {<br /> print_error('nopermissiontoviewforum');<br /> }<br /> * If you just want to assert a capability and then finish with an error message if it's not met (as we did above), then a shorter way it to use require_capability() like this:<br /> <br /> require_capability('mod/forum:viewforum', $context);<br /> <br /> * Note that there are extra parameters you can specify to get a custom error message, otherwise users get an automated &quot;No permissions&quot; message that lists the permission they were missing.<br /> <br /> <br /> As a result of the new Roles System, all calls to isadmin(), iscoursecreator, isteacheredit(), isteacher(), isstudent(), and isguest() will have to be replaced with calls to has_capability() or require_capability(). However, these functions will be retained for some backward compatibility with old code, using the legacy capabilities to try and work out what to do.<br /> <br /> ==Metacourses==<br /> <br /> The behaviour of metacourses in Moodle 1.7 changed slightly, in that where it used to just synch students from child courses to the parent course, it will now synch ALL roles. Teachers etc of the child courses will have the same role in the meta course. Technically metacourse synchronises all role assignments in CONTEXT_COURSE with its child courses; the only exception are users with moodle/course:managemetacourse capability, these users are synchronized only upwards, they are not unenrolled from metacourse when unenroling from child course or when removing the child from metacourse.<br /> <br /> In order to import/enrol other courses into metacoure you need to have moodle/course:managemetacourse capability. You can add manually only participants with moodle/course:managemetacourse, all other participants are automatically synced with child courses - if you try to manually enrol user without this capability error is displayed. Similar error is shown also when you try to manually unenrol participant from meta course while still being enrolled in child course.<br /> <br /> Sample setup:<br /> * metacourse manager has been assigned role with moodle/course:managemetacourse capability in system or course category context<br /> * students are enrolled in several child courses<br /> * teachers are enrolled in separate child course(s)<br /> <br /> ==Problem areas we are working on ==<br /> <br /> ===Student view===<br /> <br /> The &quot;Student view&quot; button has been removed completely.<br /> <br /> If there is time and a secure way can be found, it will be replaced by a menu to let the user assume a temporary role in the context of that course.<br /> <br /> ===Teacher forum===<br /> <br /> Teacher forums were always a curious exception to normal forums, as they were not part of a course as such, and were not backed up.<br /> <br /> We're taking the opportunity to rectify this. The upgrade converts teacher forums with content to normal forums in section 0 of the course, and ensures that only teachers can access them. If the teacher forum had not been used in the course then it's not converted and will just dissappear.<br /> <br /> ===Enrolment plugins===<br /> <br /> ====Process of logging in====<br /> <br /> # load_user_capability() is called to load all the capabilities<br /> # check_enrolment_plugins() is called at the top of load_user_capability() to check all the enrolment plugins.<br /> # For each active plugin:<br /> ##Check for setup_enrolments($user) and run it. This function will do all the processing needed to assign or unassign roles from the current user.<br /> # load_user_capability() continues and loads up all the roles<br /> # load_defaultuser_role() is called to add default site permissions (all users)<br /> <br /> ====Process of checking access to a course====<br /> <br /> require_login($course-&gt;id) is called by the script and has logic like this:<br /> <br /> # Is the user a guest at site level?<br /> ## Yes: Does the course allow guests?<br /> ### Yes: return true (and further capabilities are checked by the script)<br /> ### No: send the user to course/enrol.php for enrolment<br /> ## No: continue below<br /> <br /> # Does the user have moodle/course:view in that (course) context?<br /> ## Yes: then they can enter (and further capabilities are checked by the script)<br /> ## No: is guest access allowed on the course?<br /> ### Yes: assign temporary guest role to that user for that context (in session cache).<br /> ### No: send the user to course/enrol.php for enrolment.<br /> <br /> ====Process of enrolling====<br /> <br /> (more soon)<br /> <br /> ==Scenario brainstorming==<br /> <br /> This section is for brainstorming some example roles that we would like to support. Note some of these *may* not be possible in 1.7.<br /> <br /> ===Student===<br /> Obviously.<br /> <br /> ===Site Designers===<br /> Is there a role for people involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.<br /> <br /> ===Educational Authority Adviser===<br /> Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.<br /> <br /> ===Educational Inspector===<br /> Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.<br /> <br /> ===Second Marker / Moderator===<br /> A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.<br /> <br /> ===Peer observer of teaching===<br /> Many institutions encourage peer observation of teaching, to encourage reflection on practice. In online environments this will be similar to moderation or inspection. The peer observer would need to be able to experience the course &quot;as a student&quot;, but also to be able to view summaries of usage, transcripts of interactions (forums/surveys/polls etc), grades assigned (e.g. in assignments).<br /> <br /> ===External Examiner===<br /> Has all the rights of inspectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.<br /> <br /> ===Parent===<br /> A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.<br /> <br /> In Early Years (EY=3+4 yr olds) and Key Stage 1 (KS1=5+6 yr olds) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary. In Key Stage 2 (KS2=7-11 yr olds) parents would be more monitoring but may join in as well.<br /> <br /> In Key stages 3 (KS3=12-14 yr olds) and 4 (KS4=15+16 yr olds) this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.<br /> <br /> In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments. Also in all Key Satges there may be a home-school agreement which may be signed up to. Could this form part of a site policy system that incorporates a tickable list of activities the parent agrees to the child using (blogs/wikis/forums etc.)?<br /> <br /> Parent's evenings often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.<br /> <br /> In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face. <br /> <br /> The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.<br /> <br /> In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.<br /> <br /> Again in the UK, parents have their own independent right of access to a child's educational records. Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.<br /> <br /> There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.<br /> <br /> ===Manager===<br /> ''Please add text here...''<br /> <br /> ===Weekly Seminar Leader===<br /> ''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus &quot;Allow Quiz Authoring Role&quot; or &quot;Allow Assignment Authoring Role&quot; at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''<br /> <br /> ===Mentor/Mentee===<br /> ''Please add text here...''<br /> <br /> ===Community-Designed Rating Criteria===<br /> ''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''<br /> <br /> ===Visitor===<br /> <br /> This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant.<br /> <br /> ===Guest Speaker===<br /> <br /> This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have &quot;guest speakers&quot; who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.<br /> <br /> ===Former Student===<br /> This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?<br /> <br /> ===Alumnus=== An ALUMNUS should be able to search for all other ALUMNI of the school, interact with them and be enrolled in a seperate course - which is like a META course with all the content of his learning and interaction - as well as capabilities to be a part of this ALUMNI only course. All the teachers of courses during school years should automatically be a part of the ALUMNI course .. which means when an ALUMNUS is enrolled in a course, the original teachers of all his courses get enrolled ? --[[User:Anil Sharma|Anil Sharma]] 20:54, 15 July 2006 (WST)<br /> <br /> ===Librarian===<br /> <br /> Reference Librarians have an active role in most of the courses taught at some schools such as Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.<br /> <br /> In schools there is often a book review system. This may be covered by the lending system database but may not in which case a librarian may neeed to have a course area they can create a database template to handle the reviews in which case they may have a normal teacher style role? Off topic but course an integration with common schools database systems would be great.<br /> <br /> ===Teacher===<br /> <br /> Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity. <br /> <br /> I think that what is needed is a simple heirarchy of permissions and levels of granularity.<br /> <br /> I would take issue with &quot;teachers should have read access to other teacher's courses unless explicitly prohibited.&quot; This is a violation of the students' privacy as how they perform and what they do in one class isn't the business of another teacher. Moreover, in the real world a teacher wouldn't suddenly go sit in on a colleague's class without asking permission first. I would not have appreciated such an invasion of privacy as either a teacher or a student. It could be an option, but shouldn't be default.--[[User:N Hansen|N Hansen]] 19:54, 12 June 2006 (WST)<br /> <br /> ===Community Education Tutors/Trainers===<br /> Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.<br /> <br /> ===Secretary/Student Worker===<br /> <br /> We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.<br /> <br /> ===Teaching Assistant===<br /> <br /> Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker<br /> <br /> ===Student - FERPA rights===<br /> <br /> A student that has asserted their FERPA rights to non-disclosure. Typically includes not publishing their name<br /> in any public place. Could include this student only being seen with an &quot;alias&quot; within course spaces. Is this an attribute rather<br /> than a role?<br /> <br /> ===Help Desk===<br /> <br /> Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy<br /> of inheritance is needed, full access will be problematic with FERPA.<br /> <br /> ===Admin - Catgory based===<br /> <br /> Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add site-wide entries to the calendar etc.<br /> <br /> ===Process Roles===<br /> <br /> organising the learning process for a group you wish to have the choice to place students in differnt roles: examples of this are:<br /> * Give a student the role of forum-moderator with edit and chunk-rights<br /> * Give students different roles &amp; rights in a Webquest design (and change these roles next week<br /> * Give students different resources, depending of their roles in a rolegame/simulation<br /> * Give a student the rights to create the section content of next week (and only that week..)<br /> <br /> ==Things to finish for 1.7 Beta==<br /> '''18 Sept 2006'''<br /> <br /> #Remove core references to user_student, user_teacher, user_admin, user_coursecreator tables. [Yu]<br /> #Address function: isteacher, isadmin, isstudent [Yu]<br /> #Remove &quot;view&quot; capabilities from all modules unless required [Vy]<br /> #Remove all old references from remaining Blocks [Vy]<br /> #Metacourses [Skodak]<br /> #Add risks to GUI[Skodak]<br /> #Enrolment plugins [Martin and Alastair]<br /> #[[Stats_roles_1.7|Statistics]] [Penny]<br /> #Fix Loginas<br /> #Add category-level assigns [Yu]<br /> #[[Backup_roles_1.7|Backups]] [Eloy?]<br /> <br /> ===Proposal for interface enhancement===<br /> Martin asked some questions, here are my answers. The sketches below are not worked out proposals. Their task is to visualize the idea. The exact colours and functionality may be defined after possible agreement about the proposals. The Green, orange and red columns support the meaning of the options from &quot;allow&quot; to &quot;prohibit&quot; (If you may want to see larger images please click onto the image or the &quot;Enlarge&quot; icon below the image.)<br /> <br /> The list of possible settings is very long and '' &quot;... the problem is not to overwhelm people with information&quot; ''. <br /> <br /> [[Image:01_moodle_define_roles_structured.png|thumb=01_moodle_define_roles_structured_pre.png]]<br /> <br /> 1) One proposal is to use colour to structure the sections and the columns. Picture 1 shows that the user can keep a much better overview when the list is divided into meaningful different coloured columns and clear sections.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:02_moodle_define_roles_collapsed.png|thumb=02_moodle_define_roles_collapsed_pre.png]]<br /> <br /> 2) A second proposal is to reduce the amount of information the user is shown at the same time. The YUI interface library offers great support to show/hide sections of the page by clicking on specific elements. <br /> <br /> For example click on an icon beside the sub heading &quot;Course categories&quot; and show/hide all table rows with the CLASS &quot;course-category&quot;.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> [[Image:03_moodle_define_roles_tooltip.png|thumb=03_moodle_define_roles_tooltip_pre.png]]<br /> <br /> 3) '' &quot;The main problem is the last column for risk ... we were thinking of putting little icons in there ...&quot; ''<br /> Icons are good when they tell the user more about possible actions/meanings then the letters. I am not sure if this is the case here. For both - icons or letters - the YUI tool-tip function would be able to give the user valuable information about the meaning.<br /> &lt;br style=&quot;clear:both;&quot; /&gt;<br /> <br /> ==See also==<br /> <br /> *[[Hardening new Roles system]]<br /> *[[Roles and modules]]<br /> *Using Moodle course:<br /> **[http://moodle.org/mod/forum/view.php?f=941 Roles and Capabilities forum]<br /> **Key discussions at Using Moodle forums:<br /> ***[http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture]<br /> ***[http://moodle.org/mod/forum/discuss.php?d=56302#256313 An example of admin roles as set in the database]<br /> <br /> [[Category:Roles]]<br /> [[Category:Roles]]<br /> <br /> [[fr:Developpement:Roles]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6104 2007-01-23T20:44:36Z

<p>Martinlanghoff: /* Key config variables and functions */</p> <hr /> <div>{{Moodle 1.8}}<br /> <br /> Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for administrators is here [[Moodle Network]]<br /> * Some old documentation about the initial planning and dev<br /> ** [[Community_hub]]<br /> ** [[Community_hub_technotes]]<br /> ** [[Community_hub_progress]]<br /> <br /> =Key config variables and functions=<br /> <br /> // that mnethostid should &quot;local&quot; users have?<br /> // this is guaranteed to be set, except during the 1.7-&gt;1.8 upgrade<br /> $id = $CFG-&gt;mnet_localhost_id; <br /> <br /> // a quick way to check if our user is local<br /> is_mnet_remote_user($user); <br /> // internally wis_mnet_remote_user() does<br /> // if ($user-&gt;mnethostid == $CFG-&gt;mnet_localhost_id)<br /> <br /> // Are we listening to mnet requests? Nothing else works if we aren't.<br /> if ($CFG-&gt;mnet_dispatcher_mode === 'strict') {<br /> // Moodle is listening to mnet requests. Nothing else works if we aren't.<br /> }<br /> <br /> // Are we allowing remote users in via auth/mnet?<br /> if (is_enabled_auth('mnet')) {<br /> // yes indeed<br /> }<br /> <br /> // Will auth/mnet autocreate new user accts?<br /> if (get_config('auth/mnet', 'auto_add_remote_users')) {<br /> // yes it will!<br /> }<br /> <br /> =Protocols=<br /> <br /> ==MNET handshake==<br /> <br /> <br /> ==Authentication/SSO==<br /> <br /> <br /> ==Enrolment==<br /> <br /> <br /> =To Do=<br /> <br /> Some immediate items that would add polish without major surgery<br /> <br /> * Exchange more enrolment info at log-entry exchange time on cron<br /> * Special default role<br /> ** Add a new &quot;remote student&quot; role<br /> ** Add a config var to enrol/mnet: &quot;defaultremoterole&quot; to use &quot;remote student&quot;<br /> ** Add a config var to the courses table to optionally override defaultremoterole<br /> * Nicer CSS in the &quot;my courses&quot; listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().<br /> <br /> =Roadmap=<br /> <br /> A bit more work, and a whole lot more features. From easy to hard...<br /> <br /> * Better per-host stats and log views for administrators. This is relatively easy using data we already have.<br /> * In mod/forum craft a special URL for remote users so that the post URL is in the wantsurl parameter, so they can bounce-off their IDP in one go. <br /> ** According to Jonathan Harker, this requires that we modify jump to accept the remote wwwroot as a parameter. Also: will this be safe enough?<br /> * Display aggregated calendar on the IDP<br /> * Exchange grades. Needs a bit of design.<br /> * Build a SCORM/IMSCP/MoodleZip repository scheme.<br /> ** MartinL has some ideas on how to get this done in easy and super-scalable.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6103 2007-01-23T20:29:01Z

<p>Martinlanghoff: </p> <hr /> <div>{{Moodle 1.8}}<br /> <br /> Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for administrators is here [[Moodle Network]]<br /> * Some old documentation about the initial planning and dev<br /> ** [[Community_hub]]<br /> ** [[Community_hub_technotes]]<br /> ** [[Community_hub_progress]]<br /> <br /> =Key config variables and functions=<br /> <br /> // that mnethostid should &quot;local&quot; users have?<br /> // this is guaranteed to be set, except during the 1.7-&gt;1.8 upgrade<br /> $id = $CFG-&gt;mnet_localhost_id; <br /> <br /> // a quick way to check if our user is local<br /> is_mnet_remote_user($user); <br /> // internally wis_mnet_remote_user() does<br /> // if ($user-&gt;mnethostid == $CFG-&gt;mnet_localhost_id)<br /> <br /> // Are we listening to mnet requests? Nothing else works if we aren't.<br /> if ($CFG-&gt;mnet_dispatcher_mode === 'strict') {<br /> // Moodle is listening to mnet requests. Nothing else works if we aren't.<br /> }<br /> <br /> // Are we allowing remote users in via auth/mnet?<br /> // this is a bit more involved -- we should have a function<br /> // CFG-&gt;auth_plugins_enabled is guaranteed to be set, except during the 1.7-&gt;1.8 upgrade<br /> $auths = explode(',', $CFG-&gt;auth_plugins_enabled);<br /> if (in_array('mnet', $auths)) {<br /> // yes, auth/mnet is active <br /> }<br /> <br /> // Will auth/mnet autocreate new user accts?<br /> if (get_config('auth/mnet', 'auto_add_remote_users')) {<br /> // yes it will!<br /> }<br /> <br /> =Protocols=<br /> <br /> ==MNET handshake==<br /> <br /> <br /> ==Authentication/SSO==<br /> <br /> <br /> ==Enrolment==<br /> <br /> <br /> =To Do=<br /> <br /> Some immediate items that would add polish without major surgery<br /> <br /> * Exchange more enrolment info at log-entry exchange time on cron<br /> * Special default role<br /> ** Add a new &quot;remote student&quot; role<br /> ** Add a config var to enrol/mnet: &quot;defaultremoterole&quot; to use &quot;remote student&quot;<br /> ** Add a config var to the courses table to optionally override defaultremoterole<br /> * Nicer CSS in the &quot;my courses&quot; listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().<br /> <br /> =Roadmap=<br /> <br /> A bit more work, and a whole lot more features. From easy to hard...<br /> <br /> * Better per-host stats and log views for administrators. This is relatively easy using data we already have.<br /> * In mod/forum craft a special URL for remote users so that the post URL is in the wantsurl parameter, so they can bounce-off their IDP in one go. <br /> ** According to Jonathan Harker, this requires that we modify jump to accept the remote wwwroot as a parameter. Also: will this be safe enough?<br /> * Display aggregated calendar on the IDP<br /> * Exchange grades. Needs a bit of design.<br /> * Build a SCORM/IMSCP/MoodleZip repository scheme.<br /> ** MartinL has some ideas on how to get this done in easy and super-scalable.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6102 2007-01-23T20:28:43Z

<p>Martinlanghoff: </p> <hr /> <div>{{Moodle 1.8}}<br /> <br /> Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for end users is here [[Moodle Network]]<br /> * Some old documentation about the initial planning and dev<br /> ** [[Community_hub]]<br /> ** [[Community_hub_technotes]]<br /> ** [[Community_hub_progress]]<br /> <br /> =Key config variables and functions=<br /> <br /> // that mnethostid should &quot;local&quot; users have?<br /> // this is guaranteed to be set, except during the 1.7-&gt;1.8 upgrade<br /> $id = $CFG-&gt;mnet_localhost_id; <br /> <br /> // a quick way to check if our user is local<br /> is_mnet_remote_user($user); <br /> // internally wis_mnet_remote_user() does<br /> // if ($user-&gt;mnethostid == $CFG-&gt;mnet_localhost_id)<br /> <br /> // Are we listening to mnet requests? Nothing else works if we aren't.<br /> if ($CFG-&gt;mnet_dispatcher_mode === 'strict') {<br /> // Moodle is listening to mnet requests. Nothing else works if we aren't.<br /> }<br /> <br /> // Are we allowing remote users in via auth/mnet?<br /> // this is a bit more involved -- we should have a function<br /> // CFG-&gt;auth_plugins_enabled is guaranteed to be set, except during the 1.7-&gt;1.8 upgrade<br /> $auths = explode(',', $CFG-&gt;auth_plugins_enabled);<br /> if (in_array('mnet', $auths)) {<br /> // yes, auth/mnet is active <br /> }<br /> <br /> // Will auth/mnet autocreate new user accts?<br /> if (get_config('auth/mnet', 'auto_add_remote_users')) {<br /> // yes it will!<br /> }<br /> <br /> =Protocols=<br /> <br /> ==MNET handshake==<br /> <br /> <br /> ==Authentication/SSO==<br /> <br /> <br /> ==Enrolment==<br /> <br /> <br /> =To Do=<br /> <br /> Some immediate items that would add polish without major surgery<br /> <br /> * Exchange more enrolment info at log-entry exchange time on cron<br /> * Special default role<br /> ** Add a new &quot;remote student&quot; role<br /> ** Add a config var to enrol/mnet: &quot;defaultremoterole&quot; to use &quot;remote student&quot;<br /> ** Add a config var to the courses table to optionally override defaultremoterole<br /> * Nicer CSS in the &quot;my courses&quot; listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().<br /> <br /> =Roadmap=<br /> <br /> A bit more work, and a whole lot more features. From easy to hard...<br /> <br /> * Better per-host stats and log views for administrators. This is relatively easy using data we already have.<br /> * In mod/forum craft a special URL for remote users so that the post URL is in the wantsurl parameter, so they can bounce-off their IDP in one go. <br /> ** According to Jonathan Harker, this requires that we modify jump to accept the remote wwwroot as a parameter. Also: will this be safe enough?<br /> * Display aggregated calendar on the IDP<br /> * Exchange grades. Needs a bit of design.<br /> * Build a SCORM/IMSCP/MoodleZip repository scheme.<br /> ** MartinL has some ideas on how to get this done in easy and super-scalable.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6101 2007-01-23T20:15:55Z

<p>Martinlanghoff: /* Key config variables */</p> <hr /> <div>{{Moodle 1.8}}<br /> <br /> Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for end users is here [Moodle Network]<br /> * Some old documentation about the initial planning and dev<br /> ** [[Community_hub]]<br /> ** [[Community_hub_technotes]]<br /> ** [[Community_hub_progress]]<br /> <br /> =Key config variables and functions=<br /> <br /> // that mnethostid should &quot;local&quot; users have?<br /> // this is guaranteed to be set, except during the 1.7-&gt;1.8 upgrade<br /> $id = $CFG-&gt;mnet_localhost_id; <br /> <br /> // a quick way to check if our user is local<br /> is_mnet_remote_user($user); <br /> // internally wis_mnet_remote_user() does<br /> // if ($user-&gt;mnethostid == $CFG-&gt;mnet_localhost_id)<br /> <br /> // Are we listening to mnet requests? Nothing else works if we aren't.<br /> if ($CFG-&gt;mnet_dispatcher_mode === 'strict') {<br /> // Moodle is listening to mnet requests. Nothing else works if we aren't.<br /> }<br /> <br /> // Are we allowing remote users in via auth/mnet?<br /> // this is a bit more involved -- we should have a function<br /> // CFG-&gt;auth_plugins_enabled is guaranteed to be set, except during the 1.7-&gt;1.8 upgrade<br /> $auths = explode(',', $CFG-&gt;auth_plugins_enabled);<br /> if (in_array('mnet', $auths)) {<br /> // yes, auth/mnet is active <br /> }<br /> <br /> // Will auth/mnet autocreate new user accts?<br /> if (get_config('auth/mnet', 'auto_add_remote_users')) {<br /> // yes it will!<br /> }<br /> <br /> =Protocols=<br /> <br /> ==MNET handshake==<br /> <br /> <br /> ==Authentication/SSO==<br /> <br /> <br /> ==Enrolment==<br /> <br /> <br /> =To Do=<br /> <br /> Some immediate items that would add polish without major surgery<br /> <br /> * Exchange more enrolment info at log-entry exchange time on cron<br /> * Special default role<br /> ** Add a new &quot;remote student&quot; role<br /> ** Add a config var to enrol/mnet: &quot;defaultremoterole&quot; to use &quot;remote student&quot;<br /> ** Add a config var to the courses table to optionally override defaultremoterole<br /> * Nicer CSS in the &quot;my courses&quot; listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().<br /> <br /> =Roadmap=<br /> <br /> A bit more work, and a whole lot more features. From easy to hard...<br /> <br /> * Better per-host stats and log views for administrators. This is relatively easy using data we already have.<br /> * In mod/forum craft a special URL for remote users so that the post URL is in the wantsurl parameter, so they can bounce-off their IDP in one go. <br /> ** According to Jonathan Harker, this requires that we modify jump to accept the remote wwwroot as a parameter. Also: will this be safe enough?<br /> * Display aggregated calendar on the IDP<br /> * Exchange grades. Needs a bit of design.<br /> * Build a SCORM/IMSCP/MoodleZip repository scheme.<br /> ** MartinL has some ideas on how to get this done in easy and super-scalable.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6100 2007-01-23T20:03:58Z

<p>Martinlanghoff: </p> <hr /> <div>{{Moodle 1.8}}<br /> <br /> Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for end users is here [Moodle Network]<br /> * Some old documentation about the initial planning and dev<br /> ** [[Community_hub]]<br /> ** [[Community_hub_technotes]]<br /> ** [[Community_hub_progress]]<br /> <br /> =Key config variables=<br /> <br /> <br /> =Protocols=<br /> <br /> ==MNET handshake==<br /> <br /> <br /> ==Authentication/SSO==<br /> <br /> <br /> ==Enrolment==<br /> <br /> <br /> =To Do=<br /> <br /> Some immediate items that would add polish without major surgery<br /> <br /> * Exchange more enrolment info at log-entry exchange time on cron<br /> * Special default role<br /> ** Add a new &quot;remote student&quot; role<br /> ** Add a config var to enrol/mnet: &quot;defaultremoterole&quot; to use &quot;remote student&quot;<br /> ** Add a config var to the courses table to optionally override defaultremoterole<br /> * Nicer CSS in the &quot;my courses&quot; listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().<br /> <br /> =Roadmap=<br /> <br /> A bit more work, and a whole lot more features. From easy to hard...<br /> <br /> * Better per-host stats and log views for administrators. This is relatively easy using data we already have.<br /> * In mod/forum craft a special URL for remote users so that the post URL is in the wantsurl parameter, so they can bounce-off their IDP in one go. <br /> ** According to Jonathan Harker, this requires that we modify jump to accept the remote wwwroot as a parameter. Also: will this be safe enough?<br /> * Display aggregated calendar on the IDP<br /> * Exchange grades. Needs a bit of design.<br /> * Build a SCORM/IMSCP/MoodleZip repository scheme.<br /> ** MartinL has some ideas on how to get this done in easy and super-scalable.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6099 2007-01-22T22:23:49Z

<p>Martinlanghoff: </p> <hr /> <div>{{Moodle 1.8}}<br /> <br /> Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for end users is here [Moodle Network]<br /> * Some old documentation about the initial planning and dev<br /> ** [[Community_hub]]<br /> ** [[Community_hub_technotes]]<br /> ** [[Community_hub_progress]]<br /> <br /> <br /> =To Do=<br /> <br /> Some immediate items that would add polish without major surgery<br /> <br /> * Exchange more enrolment info at log-entry exchange time on cron<br /> * Special default role<br /> ** Add a new &quot;remote student&quot; role<br /> ** Add a config var to enrol/mnet: &quot;defaultremoterole&quot; to use &quot;remote student&quot;<br /> ** Add a config var to the courses table to optionally override defaultremoterole<br /> * Nicer CSS in the &quot;my courses&quot; listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().<br /> <br /> =Roadmap=<br /> <br /> A bit more work, and a whole lot more features. From easy to hard...<br /> <br /> * Better per-host stats and log views for administrators. This is relatively easy using data we already have.<br /> * In mod/forum craft a special URL for remote users so that the post URL is in the wantsurl parameter, so they can bounce-off their IDP in one go. <br /> ** According to Jonathan Harker, this requires that we modify jump to accept the remote wwwroot as a parameter. Also: will this be safe enough?<br /> * Display aggregated calendar on the IDP<br /> * Exchange grades. Needs a bit of design.<br /> * Build a SCORM/IMSCP/MoodleZip repository scheme.<br /> ** MartinL has some ideas on how to get this done in easy and super-scalable.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6098 2007-01-22T22:22:49Z

<p>Martinlanghoff: </p> <hr /> <div>Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for end users is here [Moodle Network]<br /> * Some old documentation about the initial planning and dev<br /> ** [[Community_hub]]<br /> ** [[Community_hub_technotes]]<br /> ** [[Community_hub_progress]]<br /> <br /> <br /> =To Do=<br /> <br /> Some immediate items that would add polish without major surgery<br /> <br /> * Exchange more enrolment info at log-entry exchange time on cron<br /> * Special default role<br /> ** Add a new &quot;remote student&quot; role<br /> ** Add a config var to enrol/mnet: &quot;defaultremoterole&quot; to use &quot;remote student&quot;<br /> ** Add a config var to the courses table to optionally override defaultremoterole<br /> * Nicer CSS in the &quot;my courses&quot; listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().<br /> <br /> =Roadmap=<br /> <br /> A bit more work, and a whole lot more features. From easy to hard...<br /> <br /> * Better per-host stats and log views for administrators. This is relatively easy using data we already have.<br /> * In mod/forum craft a special URL for remote users so that the post URL is in the wantsurl parameter, so they can bounce-off their IDP in one go. <br /> ** According to Jonathan Harker, this requires that we modify jump to accept the remote wwwroot as a parameter. Also: will this be safe enough?<br /> * Display aggregated calendar on the IDP<br /> * Exchange grades. Needs a bit of design.<br /> * Build a SCORM/IMSCP/MoodleZip repository scheme.<br /> ** MartinL has some ideas on how to get this done in easy and super-scalable.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6097 2007-01-22T22:22:24Z

<p>Martinlanghoff: </p> <hr /> <div>Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for end users is here [Moodle Network]<br /> * Some old documentation about the initial planning and dev<br /> ** [Community_hub]<br /> ** [Community_hub_technotes]<br /> ** [Community_hub_progress]<br /> <br /> <br /> =To Do=<br /> <br /> Some immediate items that would add polish without major surgery<br /> <br /> * Exchange more enrolment info at log-entry exchange time on cron<br /> * Special default role<br /> ** Add a new &quot;remote student&quot; role<br /> ** Add a config var to enrol/mnet: &quot;defaultremoterole&quot; to use &quot;remote student&quot;<br /> ** Add a config var to the courses table to optionally override defaultremoterole<br /> * Nicer CSS in the &quot;my courses&quot; listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().<br /> <br /> =Roadmap=<br /> <br /> A bit more work, and a whole lot more features. From easy to hard...<br /> <br /> * Better per-host stats and log views for administrators. This is relatively easy using data we already have.<br /> * In mod/forum craft a special URL for remote users so that the post URL is in the wantsurl parameter, so they can bounce-off their IDP in one go. <br /> ** According to Jonathan Harker, this requires that we modify jump to accept the remote wwwroot as a parameter. Also: will this be safe enough?<br /> * Display aggregated calendar on the IDP<br /> * Exchange grades. Needs a bit of design.<br /> * Build a SCORM/IMSCP/MoodleZip repository scheme.<br /> ** MartinL has some ideas on how to get this done in easy and super-scalable.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6096 2007-01-22T22:20:53Z

<p>Martinlanghoff: </p> <hr /> <div>Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for end users is here [Moodle Network]<br /> * Some old documentation about the initial planning and dev is here<br /> <br /> =To Do=<br /> <br /> Some immediate items that would add polish without major surgery<br /> <br /> * Exchange more enrolment info at log-entry exchange time on cron<br /> * Special default role<br /> ** Add a new &quot;remote student&quot; role<br /> ** Add a config var to enrol/mnet: &quot;defaultremoterole&quot; to use &quot;remote student&quot;<br /> ** Add a config var to the courses table to optionally override defaultremoterole<br /> * Nicer CSS in the &quot;my courses&quot; listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().<br /> <br /> =Roadmap=<br /> <br /> A bit more work, and a whole lot more features. From easy to hard...<br /> <br /> * Better per-host stats and log views for administrators. This is relatively easy using data we already have.<br /> * In mod/forum craft a special URL for remote users so that the post URL is in the wantsurl parameter, so they can bounce-off their IDP in one go. <br /> ** According to Jonathan Harker, this requires that we modify jump to accept the remote wwwroot as a parameter. Also: will this be safe enough?<br /> * Display aggregated calendar on the IDP<br /> * Exchange grades. Needs a bit of design.<br /> * Build a SCORM/IMSCP/MoodleZip repository scheme.<br /> ** MartinL has some ideas on how to get this done in easy and super-scalable.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Developer_documentation&diff=512 2007-01-22T22:20:29Z

<p>Martinlanghoff: /* Documentation for core components */</p> <hr /> <div>&lt;p class=&quot;note&quot;&gt;'''Note:''' New developer documentation pages should be added to the ''Development namespace'' by typing &lt;code&gt;Development:&lt;/code&gt; before the new page name i.e. &lt;code&gt;&lt;nowiki&gt;[[New page name]]&lt;/nowiki&gt;&lt;/code&gt;.&lt;br /&gt;&lt;br /&gt;If you are a developer, you probably want to change your [[Special:Preferences|preferences]] to include the Development namespace in searches.&lt;/p&gt;<br /> <br /> ==Guidelines==<br /> The following guidelines are crucial reading for anyone wanting to contribute to the Moodle code base:<br /> *[[Coding|Coding guidelines]] have to be followed by all Moodle developers<br /> *[[Moodle architecture]] spells out the basic design goals behind Moodle<br /> *[[Interface guidelines]] aim to provide a common feel to the Moodle user interface<br /> *[[CVS (developer)|Moodle CVS for developers]] explains how to work with the Moodle code in CVS<br /> *[[Unit tests]] explains how to run the unit tests, and how to write new test cases.<br /> *[[Tracker]] explains the Moodle Tracker for keeping track of bugs, issues, feature requests etc<br /> *[[Working with the Community|Working with the Community]] explains how to engage with the dev community and discuss changes<br /> <br /> == Resources and tools ==<br /> <br /> *[[Developer FAQ]] - frequently asked questions, especially useful for newcomers to Moodle<br /> *[http://tracker.moodle.org/ Moodle tracker] - bug reports, feature requests and other tracked issues<br /> *[http://moodle.org/mod/forum/view.php?id=55 General developer forum]<br /> *[http://moodle.cvs.sourceforge.net/moodle/moodle/ CVS code] - browse the Moodle code via the web<br /> *[http://moodle.org/xref/nav.html?index.html Cross reference] - phpxref output for browsing Moodle source code<br /> *[http://phpdocs.moodle.org/ Moodle PHP doc reference] - automatically generated documentation<br /> *[[Database Schema|Database Schema]] - for recent releases<br /> *[http://moodle.org/course/view.php?id=5#4 Development news and discussion] section of Using Moodle course<br /> *[http://developer.yahoo.com/yui YUI documentation] - YUI is the official AJAX library in moodle.<br /> *[[Setting up Eclipse for Moodle development]] - Eclipse is a great editor to use for php development, if you can work out how to set it up.<br /> *[[Unmerged files]] - changes on the stable branch in CVS that have not been merged to HEAD<br /> <br /> ==How you can contribute==<br /> <br /> The M in Moodle stands for 'Modular'. There are many different types of components that you can contribute that can be plugged into Moodle to provide additional functionality. When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 database of Moodle modules and plugins]. The following types of plugins currently exist (in alphabetical order):<br /> *[[Modules (developer)|Activity modules]]<br /> *[[Admin reports|Admin reports]]<br /> *[[Assignment types]]<br /> *[[Authentication|Authentication methods]]<br /> *[[Blocks|Blocks]]<br /> *[[Course formats]]<br /> *[[Database fields (developer)|Database fields]]<br /> *[[Database presets]]<br /> *[[Enrolment plugins (developer)|Enrolment plugins]]<br /> *[[Filters|Filters]]<br /> *[[Question_engine]]<br /> *[[Question import/export formats]]<br /> *[[Question bank|Question bank teacher docs]]<br /> *[[Question_engine#Question_types|Question types developper docs]]<br /> *[[Quiz reports]]<br /> *[[Resource types]]<br /> *[[SSO plugins]]<br /> <br /> There are also ways you can contribute that don't involve PHP programming:<br /> *[[Themes]]<br /> *[[Translation]]<br /> *[[Database Schemas|Database schemas]]<br /> <br /> You can also help a lot by<br /> *[[Tests|Testing]]<br /> *[[Tracker|Participating in the bug tracker]]<br /> <br /> ==Plans for the future==<br /> Ideas for and details of planned future features of Moodle are initially discussed on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course at moodle.org. That developer discussions are intermixed with user discussions in the same forums may seem strange at first but is one of the reasons for the success of Moodle. It is important that both end-users and developers discuss the future features together.<br /> <br /> Once ideas begin to crystalize on the forums they can be summarized in this wiki, either as part of the [[Roadmap]] or in the form of [[Developer notes]]. These pages then form the basis for further discussion in the forums.<br /> *[[Roadmap]]<br /> *[[Developer notes]]<br /> *[[Student projects]]<br /> *[[Developer conference|Developer conferences]]<br /> <br /> ==Documentation for core components==<br /> This section is for documentation of specific components of the existing core Moodle code. Discussion of components that are under discussion or in development can be found in the [[Developer notes]] or on the [[Roadmap]].<br /> <br /> *[[Migration to Role-driven model|Migration to Role-driven model]] @ v[[1.7]]<br /> *[[UTF-8 migration|Migration to UTF-8]] @ v[[:Category:Moodle 1.6|1.6]]<br /> *[[Question engine]]<br /> *[[Quiz developer docs|Quiz module]]<br /> *[[SCORM schema|SCORM module 1.5 schema]]<br /> *[[Authentication API]]<br /> *[[Stats package]]<br /> *[[Email processing]]<br /> *[[Cookieless Sessions]]<br /> *[[lib/formslib.php|Formslib]] for quickly writing code to display and process more accessible and secure forms.<br /> *[[Moodle Network|Moodle Network]]<br /> <br /> ==Documentation for contributed code==<br /> Many Moodle users contribute code for the benefit of other Moodle users. This can take the form of new activity modules, blocks, themes, resource plug-ins, assignment plug-ins, question type plug-ins, question import/export formats, quiz report plug-ins, course formats, ... This code is initially posted on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course and then often go into the [http://cvs.sourceforge.net/viewcvs.py/moodle/contrib/ contrib area] of the Moodle [[CVS]] repository. When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 database of Moodle modules and plugins]. Developer documentation for these components should be listed here.<br /> <br /> ==See also==<br /> *[http://security.moodle.org/ Moodle Security Centre]<br /> *[http://moodle.com/partners/ Moodle Partners] - providers of custom Moodle development services<br /> <br /> <br /> [[es:Documentación para Desarrolladores]]<br /> [[fr:Documentation développeur]]<br /> [[zh:开发者文档]]<br /> [[ja:開発者ドキュメント]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6095 2007-01-22T22:19:25Z

<p>Martinlanghoff: </p> <hr /> <div>Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for end users is here [Moodle Network]<br /> * Some old documentation about the initial planning and dev is here<br /> <br /> =To Do=<br /> <br /> Some immediate items that would add polish without major surgery<br /> <br /> * Exchange more enrolment info at log-entry exchange time on cron<br /> * Special default role<br /> ** Add a new &quot;remote student&quot; role<br /> ** Add a config var to enrol/mnet: &quot;defaultremoterole&quot; to use &quot;remote student&quot;<br /> ** Add a config var to the courses table to optionally override defaultremoterole<br /> * Nicer CSS in the &quot;my courses&quot; listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().<br /> <br /> =Roadmap=<br /> <br /> A bit more work, and a whole lot more features. From easy to hard...<br /> <br /> * Better per-host stats and log views for administrators. This is relatively easy using data we already have.<br /> * In mod/forum craft a special URL for remote users so that the post URL is in the wantsurl parameter, so they can bounce-off their IDP in one go. <br /> ** According to Jonathan Harker, this requires that we modify jump to accept the remote wwwroot as a parameter. Also: will this be safe enough?<br /> * Display aggregated calendar on the IDP<br /> * Exchange grades. Needs a bit of design.<br /> * Build a SCORM/IMSCP/MoodleZip repository scheme.<br /> ** MartinL has some ideas on how to get this done in easy and super-scalable.<br /> <br /> <br /> <br /> [[Category:Administrator]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6094 2007-01-22T22:15:52Z

<p>Martinlanghoff: /* Roadmap */</p> <hr /> <div>Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for end users is here [Moodle Network]<br /> * Some old documentation about the initial planning and dev is here<br /> <br /> =To Do=<br /> <br /> Some immediate items that would add polish without major surgery<br /> <br /> * Exchange more enrolment info at log-entry exchange time on cron<br /> * Special default role<br /> ** Add a new &quot;remote student&quot; role<br /> ** Add a config var to enrol/mnet: &quot;defaultremoterole&quot; to use &quot;remote student&quot;<br /> ** Add a config var to the courses table to optionally override defaultremoterole<br /> * Nicer CSS in the &quot;my courses&quot; listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().<br /> <br /> =Roadmap=<br /> <br /> A bit more work, and a whole lot more features. From easy to hard...<br /> <br /> * Better per-host stats and log views for administrators. This is relatively easy using data we already have.<br /> * In mod/forum craft a special URL for remote users so that the post URL is in the wantsurl parameter, so they can bounce-off their IDP in one go. <br /> ** According to Jonathan Harker, this requires that we modify jump to accept the remote wwwroot as a parameter. Also: will this be safe enough?<br /> * Display aggregated calendar on the IDP<br /> * Exchange grades. Needs a bit of design.<br /> * Build a SCORM/IMSCP/MoodleZip repository scheme.<br /> ** MartinL has some ideas on how to get this done in easy and super-scalable.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6093 2007-01-22T22:10:08Z

<p>Martinlanghoff: /* ToDo */</p> <hr /> <div>Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for end users is here [Moodle Network]<br /> * Some old documentation about the initial planning and dev is here<br /> <br /> =To Do=<br /> <br /> Some immediate items that would add polish without major surgery<br /> <br /> * Exchange more enrolment info at log-entry exchange time on cron<br /> * Special default role<br /> ** Add a new &quot;remote student&quot; role<br /> ** Add a config var to enrol/mnet: &quot;defaultremoterole&quot; to use &quot;remote student&quot;<br /> ** Add a config var to the courses table to optionally override defaultremoterole<br /> * Nicer CSS in the &quot;my courses&quot; listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().<br /> <br /> =Roadmap=</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=MNet&diff=6092 2007-01-22T22:05:49Z

<p>Martinlanghoff: </p> <hr /> <div>Random notes for Moodle Network. Should get these organised...<br /> <br /> * Documentation for end users is here [Moodle Network]<br /> * Some old documentation about the initial planning and dev is here<br /> <br /> =ToDo=<br /> <br /> =Roadmap=</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Roadmap&diff=26155 2007-01-22T21:59:01Z

<p>Martinlanghoff: /* Version 1.8 - Expected January 2007 */</p> <hr /> <div>This roadmap collects the best information about upcoming features in Moodle. It is not 100% certain - features may change according to available funding and developers.<br /> <br /> == Version 1.8 - Expected January 2007 ==<br /> <br /> * [[Accessibility]] - Moodle.com <br /> :: Compliance with all major accessibility standards<br /> * [[Moodle forms library]] - Moodle.com <br /> :: All forms can now use a single API for defining forms consistently and collecting data safely.<br /> * [[Multi Authentication]] - Iñaki Arenaza / Jonathan Harker (Catalyst) / Martin Langhoff (Catalyst)<br /> * [[Development:Customisable user profiles|Customisable User Profiles]] - Pukunui Technology<br /> ::Allow fields to be added to the user profile.<br /> * [[Moodle Network]] - Catalyst and Moodle.com<br /> :: Setup peer Moodle installations allowing users to roam across, using comprehensive SSO and transparent remote enrolments. Administrators at the originating Moodle install can see logs of remote activity. You can also run your Moodle in &quot;Hub&quot; mode where any Moodle install can connect and users roam across.<br /> ::[[Web Services API]] for Moodle communications. The Moodle Network code includes an XML-RPC call dispatcher that can expose the whole Moodle API to trusted hosts.<br /> * Groups refactor - Juliette White / Nick Freear (OU)<br /> ::Groups code will be reorganised to make it more flexible for the future (see 1.9)<br /> * Blog commenting <br /> :: You'll be able to make comments on blogs! In time, all comments in Moodle will be merged into the same commenting system.<br /> * [[Authorize.net Payment Gateway]] enrolment plugin <br /> :: Payment managers can obtain an authorization code over phone from customer's bank if the credit card of the user cannot be captured on the internet directly.<br /> * SCORM 2004?<br /> * New Wiki?<br /> <br /> == Version 1.9 - Expected April 2007 ==<br /> <br /> * [[Repository API]] - Open University, Moodle.com and Humboldt<br /> ::Abstract all file operations to an API that allows plugins for different external repositories<br /> * [[Learning Design export]] - Moodle.com and Open University of The Netherlands<br /> ::We plan to have a very simple export for any Moodle course into IMS LD format, as a proof of concept and to help the community start learning about IMS LD.<br /> * New groups - Open University<br /> ::Site-wide groups, reusable groups, and assigning activities to groups are the major improvements being developed <br /> * [[Development:Gradebook development|Gradebook development]]<br /> ::The gradebook system will be revamped for performance, switching from our older &quot;pull&quot; model to a &quot;push&quot; model where all modules will now publish grades as necessary into a central table.<br /> * [[Metadata]] - Moodle.com<br /> ::Build on the keywords in 1.6 to provide metadata for all activities and courses, linkable to standard lists of metadata such as State-based learning outcomes and curricula<br /> <br /> == Version 2.0 - Expected July 2007 ==<br /> <br /> * [[IMS Learning Design]] - Moodle.com<br /> ::Support for importing/exporting LD, converting Moodle activities and sequences of activities into a standard format for sharing, and importing standard sequences into Moodle courses<br /> * [[Conditional activities]] - Moodle.com<br /> ::Allowing dependencies and forced paths through the content<br /> * [[Community hub]] interfaces - Moodle.com and others<br /> ::Makes it easy for users to find and navigate other systems and external Moodle repositories, leveraging the Moodle Network in various ways.<br /> * [[Student Information API]]<br /> ::API for integrating external systems for managing student information<br /> <br /> ''Note: Moodle 2.0 will require PHP 5.1 as a minimum, because of certain improvements not available in PHP 4.''<br /> <br /> <br /> == Version 2.1 ==<br /> <br /> * [[Portfolio API]]<br /> ::Interface Moodle activities and repositories to help produce portfolios for internal assessment AND external publication<br /> <br /> <br /> <br /> [[Category:Developer]]<br /> [[Category:Future]]<br /> <br /> [[es:Planificación]]<br /> [[fr:Planification]]</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Working_with_the_Community&diff=5588 2006-12-14T23:20:57Z

<p>Martinlanghoff: </p> <hr /> <div>The goal of the Moodle community is to provide the best possible LMS there is. When you submit a patch (or new module, plugin or filter) for acceptance, it will be reviewed on its technical merits and those alone. So, what should you be expecting?<br /> <br /> * criticism<br /> * comments<br /> * requests for change<br /> * requests for justification<br /> * silence<br /> * pointers to another subproject with the same goals<br /> <br /> Remember, this is part of getting your patch into Moodle. You have<br /> to be able to take criticism and comments about your patches, evaluate<br /> them at a technical level and either rework your patches or provide<br /> clear and concise reasoning as to why those changes should not be made.<br /> If there are no responses to your posting, wait a few days and try<br /> again, sometimes things get lost in the huge volume.<br /> <br /> What should you not do?<br /> * expect your patch to be accepted without question<br /> * become defensive<br /> * ignore comments<br /> * resubmit the patch without making any of the requested changes<br /> <br /> In a community that is looking for the best technical solution possible,<br /> there will always be differing opinions on how beneficial a patch is.<br /> You have to be cooperative, and willing to adapt your idea to fit within<br /> Moodle. Or at least be willing to prove your idea is worth it.<br /> Remember, being wrong is acceptable as long as you are willing to work<br /> toward a solution that is right.<br /> <br /> ==Differences between the Moodle community and corporate structures==<br /> <br /> The Moodle community works differently than most traditional corporate development environments. Here is a list of things that you can try to do to try to avoid problems:<br /> <br /> '''Good''' things to say regarding your proposed changes:<br /> * &quot;This solves multiple problems.&quot;<br /> * &quot;This deletes 2000 lines of code.&quot;<br /> * &quot;Here is a patch that explains what I am trying to describe.&quot;<br /> * &quot;I tested it on 5 different databases...&quot;<br /> * &quot;Here is a series of small patches that...&quot;<br /> * &quot;This increases performance on typical machines...&quot;<br /> <br /> '''Bad''' things you should avoid saying:<br /> * &quot;We did it this way in WebCT/Blackboard, so therefore it must begood...&quot;<br /> * &quot;I've being doing this for 20 years, so...&quot;<br /> * &quot;It makes this proprietary benchmark go faster&quot;<br /> * &quot;This is required for my company to make money&quot;<br /> * &quot;This is for our Enterprise product line.&quot;<br /> * &quot;Here is my 1000 page design document that describes my idea&quot;<br /> * &quot;I've been working on this for 6 months...&quot;<br /> * &quot;Here's a 5000 line patch that...&quot;<br /> * &quot;I rewrote all of the current mess, and here it is...&quot;<br /> * &quot;I have a deadline, and this patch needs to be applied now.&quot;<br /> <br /> Another way the Moodle community is different than most traditional<br /> software engineering work environments is the faceless nature of<br /> interaction. One benefit of using email and forums as the primary forms of<br /> communication is the lack of discrimination based on gender or race.<br /> The Moodle work environment is accepting of women and minorities<br /> because all you are is an email address. The international aspect also<br /> helps to level the playing field because you can't guess gender based on<br /> a person's name. A man may be named Andrea and a woman may be named Pat.<br /> <br /> The language barrier can cause problems for some people who are not<br /> comfortable with English. A good grasp of the language can be needed in<br /> order to get ideas across properly on forums, so it is<br /> recommended that you check your emails to make sure they make sense in<br /> English before sending them.<br /> <br /> ==Break your changes up==<br /> <br /> The Moodle community does not gladly accept large chunks of code<br /> dropped on it all at once. The changes need to be properly introduced,<br /> discussed, and broken up into tiny, individual portions. This is almost<br /> the exact opposite of what companies are used to doing. Your proposal<br /> should also be introduced very early in the development process, so that<br /> you can receive feedback on what you are doing. It also lets the<br /> community feel that you are working with them, and not simply using them<br /> as a dumping ground for your feature. However, don't post 50 times at<br /> once in the forums! <br /> <br /> The reasons for breaking things up are the following:<br /> <br /> # Small patches increase the likelihood that your patches will be applied, since they don't take much time or effort to verify for correctness. A 5 line patch can be applied by a maintainer with barely a second glance. However, a 500 line patch may take hours to review for correctness (the time it takes is exponentially proportional to the size of the patch, or something). Small patches also make it very easy to debug when something goes wrong. It's much easier to back out patches one by one than it is to dissect a very large patch after it's been applied (and broken something).<br /> # It's important not only to send small patches, but also to rewrite and simplify (or simply re-order) patches before submitting them.<br /> <br /> It may be challenging to keep the balance between presenting an elegant<br /> solution and working together with the community and discuss your<br /> unfinished work. Therefore it is good to get early in the process to<br /> get feedback to improve your work, but also keep your changes in small<br /> chunks that they may get already accepted, even when your whole task is<br /> not ready for inclusion now.<br /> <br /> Also realize that it is not acceptable to send patches for inclusion<br /> that are unfinished and will be &quot;fixed up later.&quot;<br /> <br /> ==Justify your change==<br /> <br /> Along with breaking up your patches, it is very important for you to let<br /> the Moodle community know why they should add this change. New features<br /> must be justified as being needed and useful.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Working_with_the_Community&diff=5587 2006-12-14T23:18:36Z

<p>Martinlanghoff: /* Differences between the Moodle community and corporate structures */</p> <hr /> <div>The goal of the Moodle community is to provide the best possible LMS there is. When you submit a patch (or new module, plugin or filter) for acceptance, it will be reviewed on its technical merits and those alone. So, what should you be expecting?<br /> <br /> * criticism<br /> * comments<br /> * requests for change<br /> * requests for justification<br /> * silence<br /> <br /> Remember, this is part of getting your patch into Moodle. You have<br /> to be able to take criticism and comments about your patches, evaluate<br /> them at a technical level and either rework your patches or provide<br /> clear and concise reasoning as to why those changes should not be made.<br /> If there are no responses to your posting, wait a few days and try<br /> again, sometimes things get lost in the huge volume.<br /> <br /> What should you not do?<br /> * expect your patch to be accepted without question<br /> * become defensive<br /> * ignore comments<br /> * resubmit the patch without making any of the requested changes<br /> <br /> In a community that is looking for the best technical solution possible,<br /> there will always be differing opinions on how beneficial a patch is.<br /> You have to be cooperative, and willing to adapt your idea to fit within<br /> Moodle. Or at least be willing to prove your idea is worth it.<br /> Remember, being wrong is acceptable as long as you are willing to work<br /> toward a solution that is right.<br /> <br /> ==Differences between the Moodle community and corporate structures==<br /> <br /> The Moodle community works differently than most traditional corporate development environments. Here is a list of things that you can try to do to try to avoid problems:<br /> <br /> '''Good''' things to say regarding your proposed changes:<br /> * &quot;This solves multiple problems.&quot;<br /> * &quot;This deletes 2000 lines of code.&quot;<br /> * &quot;Here is a patch that explains what I am trying to describe.&quot;<br /> * &quot;I tested it on 5 different databases...&quot;<br /> * &quot;Here is a series of small patches that...&quot;<br /> * &quot;This increases performance on typical machines...&quot;<br /> <br /> '''Bad''' things you should avoid saying:<br /> * &quot;We did it this way in WebCT/Blackboard, so therefore it must begood...&quot;<br /> * &quot;I've being doing this for 20 years, so...&quot;<br /> * &quot;It makes this proprietary benchmark go faster&quot;<br /> * &quot;This is required for my company to make money&quot;<br /> * &quot;This is for our Enterprise product line.&quot;<br /> * &quot;Here is my 1000 page design document that describes my idea&quot;<br /> * &quot;I've been working on this for 6 months...&quot;<br /> * &quot;Here's a 5000 line patch that...&quot;<br /> * &quot;I rewrote all of the current mess, and here it is...&quot;<br /> * &quot;I have a deadline, and this patch needs to be applied now.&quot;<br /> <br /> Another way the Moodle community is different than most traditional<br /> software engineering work environments is the faceless nature of<br /> interaction. One benefit of using email and forums as the primary forms of<br /> communication is the lack of discrimination based on gender or race.<br /> The Moodle work environment is accepting of women and minorities<br /> because all you are is an email address. The international aspect also<br /> helps to level the playing field because you can't guess gender based on<br /> a person's name. A man may be named Andrea and a woman may be named Pat.<br /> <br /> The language barrier can cause problems for some people who are not<br /> comfortable with English. A good grasp of the language can be needed in<br /> order to get ideas across properly on forums, so it is<br /> recommended that you check your emails to make sure they make sense in<br /> English before sending them.<br /> <br /> ==Break your changes up==<br /> <br /> The Moodle community does not gladly accept large chunks of code<br /> dropped on it all at once. The changes need to be properly introduced,<br /> discussed, and broken up into tiny, individual portions. This is almost<br /> the exact opposite of what companies are used to doing. Your proposal<br /> should also be introduced very early in the development process, so that<br /> you can receive feedback on what you are doing. It also lets the<br /> community feel that you are working with them, and not simply using them<br /> as a dumping ground for your feature. However, don't post 50 times at<br /> once in the forums! <br /> <br /> The reasons for breaking things up are the following:<br /> <br /> # Small patches increase the likelihood that your patches will be applied, since they don't take much time or effort to verify for correctness. A 5 line patch can be applied by a maintainer with barely a second glance. However, a 500 line patch may take hours to review for correctness (the time it takes is exponentially proportional to the size of the patch, or something). Small patches also make it very easy to debug when something goes wrong. It's much easier to back out patches one by one than it is to dissect a very large patch after it's been applied (and broken something).<br /> # It's important not only to send small patches, but also to rewrite and simplify (or simply re-order) patches before submitting them.<br /> <br /> It may be challenging to keep the balance between presenting an elegant<br /> solution and working together with the community and discuss your<br /> unfinished work. Therefore it is good to get early in the process to<br /> get feedback to improve your work, but also keep your changes in small<br /> chunks that they may get already accepted, even when your whole task is<br /> not ready for inclusion now.<br /> <br /> Also realize that it is not acceptable to send patches for inclusion<br /> that are unfinished and will be &quot;fixed up later.&quot;<br /> <br /> ==Justify your change==<br /> <br /> Along with breaking up your patches, it is very important for you to let<br /> the Moodle community know why they should add this change. New features<br /> must be justified as being needed and useful.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Working_with_the_Community&diff=5586 2006-12-14T23:17:28Z

<p>Martinlanghoff: /* Break your changes up */</p> <hr /> <div>The goal of the Moodle community is to provide the best possible LMS there is. When you submit a patch (or new module, plugin or filter) for acceptance, it will be reviewed on its technical merits and those alone. So, what should you be expecting?<br /> <br /> * criticism<br /> * comments<br /> * requests for change<br /> * requests for justification<br /> * silence<br /> <br /> Remember, this is part of getting your patch into Moodle. You have<br /> to be able to take criticism and comments about your patches, evaluate<br /> them at a technical level and either rework your patches or provide<br /> clear and concise reasoning as to why those changes should not be made.<br /> If there are no responses to your posting, wait a few days and try<br /> again, sometimes things get lost in the huge volume.<br /> <br /> What should you not do?<br /> * expect your patch to be accepted without question<br /> * become defensive<br /> * ignore comments<br /> * resubmit the patch without making any of the requested changes<br /> <br /> In a community that is looking for the best technical solution possible,<br /> there will always be differing opinions on how beneficial a patch is.<br /> You have to be cooperative, and willing to adapt your idea to fit within<br /> Moodle. Or at least be willing to prove your idea is worth it.<br /> Remember, being wrong is acceptable as long as you are willing to work<br /> toward a solution that is right.<br /> <br /> ==Differences between the Moodle community and corporate structures==<br /> <br /> The Moodle community works differently than most traditional corporate development environments. Here is a list of things that you can try to do to try to avoid problems:<br /> <br /> Good things to say regarding your proposed changes:<br /> * &quot;This solves multiple problems.&quot;<br /> * &quot;This deletes 2000 lines of code.&quot;<br /> * &quot;Here is a patch that explains what I am trying to describe.&quot;<br /> * &quot;I tested it on 5 different databases...&quot;<br /> * &quot;Here is a series of small patches that...&quot;<br /> * &quot;This increases performance on typical machines...&quot;<br /> <br /> Bad things you should avoid saying:<br /> * &quot;We did it this way in WebCT/Blackboard, so therefore it must begood...&quot;<br /> * &quot;I've being doing this for 20 years, so...&quot;<br /> * &quot;It makes this proprietary benchmark go faster&quot;<br /> * &quot;This is required for my company to make money&quot;<br /> * &quot;This is for our Enterprise product line.&quot;<br /> * &quot;Here is my 1000 page design document that describes my idea&quot;<br /> * &quot;I've been working on this for 6 months...&quot;<br /> * &quot;Here's a 5000 line patch that...&quot;<br /> * &quot;I rewrote all of the current mess, and here it is...&quot;<br /> * &quot;I have a deadline, and this patch needs to be applied now.&quot;<br /> <br /> Another way the Moodle community is different than most traditional<br /> software engineering work environments is the faceless nature of<br /> interaction. One benefit of using email and forums as the primary forms of<br /> communication is the lack of discrimination based on gender or race.<br /> The Moodle work environment is accepting of women and minorities<br /> because all you are is an email address. The international aspect also<br /> helps to level the playing field because you can't guess gender based on<br /> a person's name. A man may be named Andrea and a woman may be named Pat.<br /> <br /> The language barrier can cause problems for some people who are not<br /> comfortable with English. A good grasp of the language can be needed in<br /> order to get ideas across properly on forums, so it is<br /> recommended that you check your emails to make sure they make sense in<br /> English before sending them.<br /> <br /> ==Break your changes up==<br /> <br /> The Moodle community does not gladly accept large chunks of code<br /> dropped on it all at once. The changes need to be properly introduced,<br /> discussed, and broken up into tiny, individual portions. This is almost<br /> the exact opposite of what companies are used to doing. Your proposal<br /> should also be introduced very early in the development process, so that<br /> you can receive feedback on what you are doing. It also lets the<br /> community feel that you are working with them, and not simply using them<br /> as a dumping ground for your feature. However, don't post 50 times at<br /> once in the forums! <br /> <br /> The reasons for breaking things up are the following:<br /> <br /> # Small patches increase the likelihood that your patches will be applied, since they don't take much time or effort to verify for correctness. A 5 line patch can be applied by a maintainer with barely a second glance. However, a 500 line patch may take hours to review for correctness (the time it takes is exponentially proportional to the size of the patch, or something). Small patches also make it very easy to debug when something goes wrong. It's much easier to back out patches one by one than it is to dissect a very large patch after it's been applied (and broken something).<br /> # It's important not only to send small patches, but also to rewrite and simplify (or simply re-order) patches before submitting them.<br /> <br /> It may be challenging to keep the balance between presenting an elegant<br /> solution and working together with the community and discuss your<br /> unfinished work. Therefore it is good to get early in the process to<br /> get feedback to improve your work, but also keep your changes in small<br /> chunks that they may get already accepted, even when your whole task is<br /> not ready for inclusion now.<br /> <br /> Also realize that it is not acceptable to send patches for inclusion<br /> that are unfinished and will be &quot;fixed up later.&quot;<br /> <br /> ==Justify your change==<br /> <br /> Along with breaking up your patches, it is very important for you to let<br /> the Moodle community know why they should add this change. New features<br /> must be justified as being needed and useful.</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Database_Schema&diff=5633 2006-11-23T01:07:14Z

<p>Martinlanghoff: </p> <hr /> <div>The files available here are in [http://fabforce.net/dbdesigner4/ DBDesigner4] format. DBDesigner4 is a schema drawing program released under GPL.<br /> <br /> The database schemas have been put together by [http://moodle.org/user/view.php?id=11101&amp;course=11 Alberto Giampani] and [http://moodle.org/user/view.php?id=192442&amp;course=11 Dario Toledo]. We are also discussing a means of creating them automatically from the new XMLDB definitions with an XML transform.<br /> <br /> Discussion of the database schemas happens either in the forum of the relevant module, or in the [http://moodle.org/mod/forum/view.php?id=45 Databases forum].<br /> <br /> =Moodle 1.7=<br /> <br /> http://moodle.org/file.php/11/moddata/forum/110/268325/db-edudist-Moodle-1.7_.rar<br /> <br /> =Moodle 1.5.3=<br /> <br /> http://moodle.org/file.php/11/moddata/forum/110/267644/Db-Edudist-Moodle1.5.3-xml.rar</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Database_Schema&diff=5632 2006-11-22T23:37:30Z

<p>Martinlanghoff: /* Moodle 1.7 */</p> <hr /> <div>The files available here are in [http://fabforce.net/dbdesigner4/ DBDesigner4] format. DBDesigner4 is a schema drawing program released under GPL.<br /> <br /> The database schemas have been put together by [http://moodle.org/user/view.php?id=11101&amp;course=11 Alberto Giampani] and [http://moodle.org/user/view.php?id=192442&amp;course=11 Dario Toledo]. We are also discussing a means of creating them automatically from the new XMLDB definitions with an XML transform.<br /> <br /> Discussion of the database schemas happens either in the forum of the relevant module, or in the [http://moodle.org/mod/forum/view.php?id=45 Databases forum].<br /> <br /> =Moodle 1.7=<br /> <br /> http://moodle.org/file.php/11/moddata/forum/110/268325/db-edudist-Moodle-1.7_.rar<br /> <br /> =Moodle 1.5.3=<br /> <br /> http://moodle.org/file.php/11/moddata/forum/110/267644/Db-Edudist-Moodle1.5.3-xml.rar</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Database_Schema&diff=5631 2006-11-22T23:37:21Z

<p>Martinlanghoff: /* Moodle 1.5.3 */</p> <hr /> <div>The files available here are in [http://fabforce.net/dbdesigner4/ DBDesigner4] format. DBDesigner4 is a schema drawing program released under GPL.<br /> <br /> The database schemas have been put together by [http://moodle.org/user/view.php?id=11101&amp;course=11 Alberto Giampani] and [http://moodle.org/user/view.php?id=192442&amp;course=11 Dario Toledo]. We are also discussing a means of creating them automatically from the new XMLDB definitions with an XML transform.<br /> <br /> Discussion of the database schemas happens either in the forum of the relevant module, or in the [http://moodle.org/mod/forum/view.php?id=45 Databases forum].<br /> <br /> =Moodle 1.7=<br /> <br /> <br /> =Moodle 1.5.3=<br /> <br /> http://moodle.org/file.php/11/moddata/forum/110/267644/Db-Edudist-Moodle1.5.3-xml.rar</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Database_Schema&diff=5630 2006-11-22T23:33:16Z

<p>Martinlanghoff: </p> <hr /> <div>The files available here are in [http://fabforce.net/dbdesigner4/ DBDesigner4] format. DBDesigner4 is a schema drawing program released under GPL.<br /> <br /> The database schemas have been put together by [http://moodle.org/user/view.php?id=11101&amp;course=11 Alberto Giampani] and [http://moodle.org/user/view.php?id=192442&amp;course=11 Dario Toledo]. We are also discussing a means of creating them automatically from the new XMLDB definitions with an XML transform.<br /> <br /> Discussion of the database schemas happens either in the forum of the relevant module, or in the [http://moodle.org/mod/forum/view.php?id=45 Databases forum].<br /> <br /> =Moodle 1.7=<br /> <br /> <br /> =Moodle 1.5.3=</div>

Martinlanghoff https://docs.moodle.org/dev/index.php?title=Developer_documentation&diff=502 2006-11-22T23:25:14Z

<p>Martinlanghoff: /* Resources and tools */</p> <hr /> <div>&lt;p class=&quot;note&quot;&gt;'''Note:''' New developer documentation pages should be added to the ''Development namespace'' by typing &lt;code&gt;Development:&lt;/code&gt; before the new page name i.e. &lt;code&gt;&lt;nowiki&gt;[[New page name]]&lt;/nowiki&gt;&lt;/code&gt;.&lt;/p&gt;<br /> <br /> ==Guidelines==<br /> The following guidelines are crucial reading for anyone wanting to contribute to the Moodle code base:<br /> *[[Coding|Coding guidelines]] have to be followed by all Moodle developers<br /> *[[Moodle architecture]] spells out the basic design goals behind Moodle<br /> *[[Interface guidelines]] aim to provide a common feel to the Moodle user interface<br /> *[[CVS (developer)|Moodle CVS for developers]] explains how to work with the Moodle code in CVS<br /> *[[Unit tests]] explains how to run the unit tests, and how to write new test cases.<br /> *[[Tracker]] explains the Moodle Tracker for keeping track of bugs, issues, feature requests etc<br /> *[[Working with the Community|Working with the Community]] explains how to engage with the dev community and discuss changes<br /> <br /> == Resources and tools ==<br /> <br /> *[[Developer FAQ]] - frequently asked questions, especially useful for newcomers to Moodle<br /> *[http://tracker.moodle.org/ Moodle tracker] - bug reports, feature requests and other tracked issues<br /> *[http://moodle.org/mod/forum/view.php?id=55 General developer forum]<br /> *[http://moodle.cvs.sourceforge.net/moodle/moodle/ CVS code] - browse the Moodle code via the web<br /> *[http://moodle.org/xref/nav.html?index.html Cross reference] - phpxref output for browsing Moodle source code<br /> *[http://phpdocs.moodle.org/ Moodle PHP doc reference] - automatically generated documentation<br /> *[[Database Schema|Database Schema]] - for recent releases<br /> *[http://moodle.org/course/view.php?id=5#4 Development news and discussion] section of Using Moodle course<br /> *[http://developer.yahoo.com/yui YUI documentation] - YUI is the official AJAX library in moodle.<br /> *[[Setting up Eclipse for Moodle development]] - Eclipse is a great editor to use for php development, if you can work out how to set it up.<br /> *[[Unmerged files]] - changes on the stable branch in CVS that have not been merged to HEAD<br /> <br /> ==How you can contribute==<br /> <br /> The M in Moodle stands for 'Modular'. There are many different types of components that you can contribute that can be plugged into Moodle to provide additional functionality. When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 database of Moodle modules and plugins]. The following types of plugins currently exist (in alphabetical order):<br /> *[[Modules (developer)|Activity modules]]<br /> *[[Admin reports|Admin reports]]<br /> *[[Assignment types]]<br /> *[[Authentication|Authentication methods]]<br /> *[[Blocks Howto|Blocks]]<br /> *[[Course formats]]<br /> *[[Database fields (developer)|Database fields]]<br /> *[[Database presets]]<br /> *[[Enrolment plugins (developer)|Enrolment plugins]]<br /> *[[Filters|Filters]]<br /> *[[Question_engine]]<br /> *[[Question import/export formats]]<br /> *[[Question bank|Question bank teacher docs]]<br /> *[[Question_engine#Question_types|Question types developper docs]]<br /> *[[Quiz reports]]<br /> *[[Resource types]]<br /> *[[SSO plugins]]<br /> <br /> There are also ways you can contribute that don't involve PHP programming:<br /> *[[Themes]]<br /> *[[Translation]]<br /> *[[Database Schemas|Database schemas]]<br /> <br /> You can also help a lot by<br /> *[[Tests|Testing]]<br /> *[[Tracker|Participating in the bug tracker]]<br /> <br /> ==Plans for the future==<br /> Ideas for and details of planned future features of Moodle are initially discussed on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course at moodle.org. That developer discussions are intermixed with user discussions in the same forums may seem strange at first but is one of the reasons for the success of Moodle. It is important that both end-users and developers discuss the future features together.<br /> <br /> Once ideas begin to crystalize on the forums they can be summarized in this wiki, either as part of the [[Roadmap]] or in the form of [[Developer notes]]. These pages then form the basis for further discussion in the forums.<br /> *[[Roadmap]]<br /> *[[Developer notes]]<br /> *[[Student projects]]<br /> *[[Developer conference|Developer conferences]]<br /> <br /> ==Documentation for core components==<br /> This section is for documentation of specific components of the existing core Moodle code. Discussion of components that are under discussion or in development can be found in the [[Developer notes]] or on the [[Roadmap]].<br /> <br /> *[[Migration to Role-driven model|Migration to Role-driven model]] @ v[[1.7]]<br /> *[[UTF-8 migration|Migration to UTF-8]] @ v[[:Category:Moodle 1.6|1.6]]<br /> *[[Question engine]]<br /> *[[Quiz developer docs|Quiz module]]<br /> *[[SCORM schema|SCORM module 1.5 schema]]<br /> *[[Authentication API]]<br /> *[[Stats package]]<br /> *[[Email processing]]<br /> *[[Cookieless Sessions]]<br /> *[[lib/formslib.php|Formslib]] for quickly writing code to display and process more accessible and secure forms.<br /> <br /> ==Documentation for contributed code==<br /> Many Moodle users contribute code for the benefit of other Moodle users. This can take the form of new activity modules, blocks, themes, resource plug-ins, assignment plug-ins, question type plug-ins, question import/export formats, quiz report plug-ins, course formats, ... This code is initially posted on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course and then often go into the [http://cvs.sourceforge.net/viewcvs.py/moodle/contrib/ contrib area] of the Moodle [[CVS]] repository. When you have developed a new component please publish it in the [http://moodle.org/mod/data/view.php?id=6009 database of Moodle modules and plugins]. Developer documentation for these components should be listed here.<br /> <br /> ==See also==<br /> *[http://security.moodle.org/ Moodle Security Centre]<br /> *[http://moodle.com/partners/ Moodle Partners] - providers of custom Moodle development services<br /> <br /> <br /> [[es:Documentación para Desarrolladores]]<br /> [[fr:Documentation développeur]]<br /> [[zh:开发者文档]]</div>

Martinlanghoff