New permissions evaluation in 2.0: Difference between revisions
From MoodleDocs
m (French link) |
|||
| (18 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Infobox Project | {{Infobox Project | ||
|name = New permissions evaluation | |name = New permissions evaluation | ||
|state = | |state = Implemented | ||
|tracker = MDL-21710 | |tracker = MDL-21710 | ||
|discussion = n/a | |discussion = n/a | ||
|assignee = [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] | |assignee = [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] | ||
}} | }} | ||
{{Moodle 2.0}} | {{Moodle 2.0}}{{Roles}} | ||
=Goals= | =Goals= | ||
The main goals are: | The main goals are to: | ||
# replace current confusing permission evaluation | # replace current confusing permission evaluation | ||
# improve performance | # improve performance | ||
| Line 17: | Line 16: | ||
=Permission evaluation algorithm= | =Permission evaluation algorithm= | ||
# find all roles with given capability used in definition or override | # find all roles with given capability used in definition or override | ||
# evaluate permissions in given context for each role separately (going from bottom to top in context tree, first found wins unless there is a CAP_PROHIBIT on any level) | # evaluate permissions in given context for each role separately (going from bottom to top in context tree, first found wins unless there is a CAP_PROHIBIT on any level above) | ||
# user has capability if he/she has at least one role which evaluated to CAP_ALLOW and at the same time no role which was evaluated to CAP_PROHIBIT | # user has capability if he/she has at least one role which evaluated to CAP_ALLOW and at the same time no role which was evaluated to CAP_PROHIBIT | ||
http://tracker.moodle.org/secure/attachment/19672/Allowed_roles.png | |||
=Performance improvements= | =Performance improvements= | ||
| Line 24: | Line 25: | ||
= Backwards compatibility= | = Backwards compatibility= | ||
The only potential problem is CAP_PREVENT in overrides when user has several conflicting roles. Originally this was highlighted as a special feature, unfortunately it was in fact the | The only potential problem is CAP_PREVENT in overrides when user has several conflicting roles. Originally this was highlighted as a special feature, unfortunately it was in fact the main source of confusion. | ||
=See also= | =See also= | ||
* [[Enrolment rewrite and role tweaks proposal]] | * [[Enrolment rewrite and role tweaks proposal]] | ||
* [[Role overrides revisited]] | |||
* [[New permission overriding UI]] | * [[New permission overriding UI]] | ||
* [[Role | * [[Role archetypes]] | ||
[[Category:Roles]] | [[Category:Roles]] | ||
[[fr:Calcul des permissions]] | |||
Latest revision as of 12:37, 7 October 2013
| New permissions evaluation | |
|---|---|
| Project state | Implemented |
| Tracker issue | MDL-21710 |
| Discussion | n/a |
| Assignee | Petr Škoda (škoďák) |
Moodle 2.0
Goals
The main goals are to:
- replace current confusing permission evaluation
- improve performance
- enable improvements in permission overriding UI
Permission evaluation algorithm
- find all roles with given capability used in definition or override
- evaluate permissions in given context for each role separately (going from bottom to top in context tree, first found wins unless there is a CAP_PROHIBIT on any level above)
- user has capability if he/she has at least one role which evaluated to CAP_ALLOW and at the same time no role which was evaluated to CAP_PROHIBIT
http://tracker.moodle.org/secure/attachment/19672/Allowed_roles.png
Performance improvements
has_capability() and get_users_by_capability() uses fixed number of queries. The result could be returned as sql query instead of database records.
Backwards compatibility
The only potential problem is CAP_PREVENT in overrides when user has several conflicting roles. Originally this was highlighted as a special feature, unfortunately it was in fact the main source of confusion.
