Role archetypes
| Role archetypes | |
|---|---|
| Project state | Implemented |
| Tracker issue | MDL-21772 |
| Discussion | n/a |
| Assignee | Petr Škoda (škoďák) |
Moodle 2.0
Goals
- Remove all roles legacy stuff
- Cleanup guest access
- Prevent accidental breaking of admin roles
- Improve performance
- Simplify coding style
- Fix some other long standing design problems
Legacy capabilities
Since 1.7 roles could be marked by setting legacy capabilities. Originally this was intended as a temporary solution for replacing of isteacher(), isstudent(), but we soon realised we need it also for upgrades when adding new capabilities and also for role resetting. Later the legacy capabilities were used for role related default settings.
Legacy guest capability was used for different purposes - course guest access and preventing students from posting.
Role archetypes
Role archetype can be specified in a new filed in role table. The difference is that the code is significantly simplified and it is not possible to use the legacy capability checks at all (we have to finally solve all legacy problems).
Redefined guest access
Originally guests had both moodle/course:view and moodle/legacy:guest, this lead to many problems because the moodle/course:view was not used exclusively for enrolments. The guest access can be fully implemented in require_login() without any giving any capability.
Redefined moodle/course:view capability
The hidden role assignments were implemented to work around the single moodle/course:view capability that was used both for enrolled users and managers or admins. Unfortunately this was very hacky solution that required hacks all over the place and was never completely implemented. Now the moodle/course:view is allowing users to enter the course without actually participating in course. They are mostly invisible to other users.
New moodle/course:participate capability
Finally the new moodle/course:participate clearly marks all participants in course - usually teachers+students. All users with this capability are displayed on the participation page. Only users with this capability may be members of groups.
Admins without a role
Since 1.7 we just kept adding hacks for hiding of administrators over and over again, we had to implemented various hacks in order to protect the admin users. Solution is very simple - do not create any admin role and instead just keep the list of admins only in $CFG->siteadmins. moodle/course:view capability grants admins the right to enter any course.
Benefits:
- admins are not returned from get_users_by_capability() - no need for $doanything there
- has_capability() - the only place where $doanything makes sense
- is_siteadmin() is extremely fast because it does not need any DB access
- much safer - nobody may get doanything capability
- no admin my_courses() exceptions needed
- nobody may "break" admins anymore
New Manager role
Manager role is supposed to replace original "small administrators" that were assigned at a course category level. moodle/course:view capability grants admins the right to enter managed course. Admins assigned in lower levels can be automatically migrated to manager role assignments. Managers are by default not enrolled in courses, they can enter them and manage them only.
Benefits:
- better control
- much easier to setup manager of course categories
Potential problems:
- we already have "course manager" admin setting which marks roles responsible for course enrolment
