Thanks very much to Remote Learner Canada, especially Hubert Chathi and Olav Jordan, for their work on the bulk of this code, and also Mike Churchward for supporting them. I worked on it after that (actually simplified it by removing a feature temporarily: multiple pages) to bring it more to what I was imagining, and to provide a base to build on and get all the navigation perfect.
There's still work to do. Some blocks don't quite work as expected, and some of the code still needs upgrading to bring it fully into line with 2.0. We also could use a much better course overview block and better CSS styling of the profile pages. But it's definitely more usable this it was, I think.
Even though I've tweaked this and done some polishing, there is still plenty to do on it now in HEAD, mostly to do with UI, usability and strings, so we'll keep working on it. Aaron already has a number of improvements to add to it.
Rather than performing complicated upgrade procedures from the old (broken) logic in three activity modules, we are adding new capabilities to those three modules to make them all consistent, and using them in a callback from the Ratings API. This is the same as the Comments API.
The downside is that two sets of capabilities need to be enabled for ratings to work. Hopefully this can be mitigated somewhat when build some sort of shortcuts on the module settings forms to set capabilities. In the meantime, the effect is reduced somewhat by having all the rating capabilities enabled by default for student and teacher roles. This means control is in the hands of whatever the modules have set, giving very close backward compatibility.
This is not the perfect solution, but neither were the other two.
* 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.
