* Allow multiple roles to be allocated by identity provider
* Allow existing enrolment plugins to manage mnet enrolments
Author: Peter Bulmer <peter.bulmer@catalyst.net.nz>
In particular for editing sticky blocks. If the admin addes one at site level,
then the teacher should not be able to change its configuration from
the course page, but should be able to set the position on this page.
1/ email notification when course requested
2/ course request capability so that we can limit who can request new course
3/ list of my pending course requests on the request form
Implemented in 1.9 by Petr Skoda, and reviewed and merged to HEAD by me.
1. If a user does not have that capability, don't let them change whether the course is visible.
2. Give teachers that capability by default.
3. To avoid regressions, on upgrade, give moodle/course:visibility to any role that has moodle/course:update.
Bugs: MDL-17479, MDL-16426, MDL-16063, MDL-16013, MDL-15658, MDL-15556, MDL-15161, MDL-14925, MDL-13742, MDL-11557.
* Simplify category editing permissions to just moodle/category:manage and moodle/category:seehiddencategories.
* Enforce those correctly. (Note MDL 17502 is still outstanding.)
* Don't screw up category sort order when you just edit name or description.
* Niceties like where redirects go when you cancel or submit forms.
* Make sure a global course creator can see the site admin block.
* Don't allow a category to be made the child of one of its children!
* General code cleanup to bring key files more in line with best pracitice.
Apologies for the fact it is one big patch, rather than a series of smaller patches. However, categoryedit.php, category.php and index.php where in pretty bad shape and needed significant cleaning up. categoryedit.php, in particular, was almost completely rewritten.
Merged from MOODLE_19_STABLE.
This is an initial implementation that is now at a working state, but with a few things left to do. It seemed like a good idea to commit it before leaving work on Friday night.
This new messaging system replaces all the various email_to_user() calls.
They are now replaced by events triggers, and the messages are then
processed centrally according to user preferences and sent to one or more
processors (email, popup, jabber etc...)
This code is not finished yet, a lot of work still has to be done on the
interface. However, the basic structure is there and should be working.
Luis and I will be reviewing and polishing this heavily in the next few weeks.
Petr Skoda