This change:
- Renames the existing setting 'extrauserselectorfields' to 'showuseridentity'
in preparation for using it in more places. (Upgrade change, new version.)
- Adds a new capability moodle/site:viewuseridentity, now required in order
to see the extra fields; if you don't have the capability, you don't see them
- Slightly improves the display of extra fields in user selector list; it used
to be like 'sam marshall, 01234567, email@address' and is now
'sam marshall [01234567, email@address]' ie the fields are in square
brackets
- Turns feature on for the group selector - the feature was enabled for other
user selectors but not for the group selector. Tim did the disable code, he
thinks this may be to do with more people having access to group selector -
probably not a problem now it is controlled by capability.
There is a new capability to manage all shared templates. Without this
capability, the user is allowed to delete just templates they previously
shared.
In the future, an option to edit the template directly might be added.
At the moment, the workaround is to pick the template into a temporary
assignment, edit it there and re-save it as a new template.
The course creator role is designed to be used to create courses, nothing else - that is create new course, create new course from backup + view hidden courses and categories.
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.
