Role archetypes: Difference between revisions
No edit summary |
No edit summary |
||
| Line 7: | Line 7: | ||
}} | }} | ||
{{Moodle 2.0}} | {{Moodle 2.0}} | ||
...work in progress... | |||
=Goals= | =Goals= | ||
| Line 17: | Line 19: | ||
* Fix some other long standing design problems | * 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. | |||
=New moodle/course:inspect 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. | |||
=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:inspect 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:inspect 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 | |||
=See also= | =See also= | ||
* [[Enrolment rewrite and role tweaks proposal]] | * [[Enrolment rewrite and role tweaks proposal]] | ||
* [[New permissions evaluation in 2.0]] | * [[New permissions evaluation in 2.0]] | ||
Revision as of 18:46, 29 March 2010
| Role archetypes | |
|---|---|
| Project state | Proposal |
| Tracker issue | MDL-21772 |
| Discussion | n/a |
| Assignee | Petr Škoda (škoďák) |
Moodle 2.0
...work in progress...
Goals
- Remove all roles legacy stuff
- Cleanup guest access
- Cleanup enrolment related code before other major changes
- 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.
New moodle/course:inspect 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.
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:inspect 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:inspect 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
