New permissions evaluation in 2.0: Difference between revisions
From MoodleDocs
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
{{Infobox Project | {{Infobox Project | ||
|name = New permissions evaluation | |name = New permissions evaluation | ||
|state = Implementation | |state = Implementation (patch in tracker) | ||
|tracker = MDL-21710 | |tracker = MDL-21710 | ||
|discussion = n/a | |discussion = n/a | ||
| Line 8: | Line 8: | ||
}} | }} | ||
{{Moodle 2.0}} | {{Moodle 2.0}} | ||
=Goals= | =Goals= | ||
| Line 14: | Line 13: | ||
# replace current confusing permission evaluation | # replace current confusing permission evaluation | ||
# improve performance | # 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) | |||
# 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 | |||
= 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 major source of confusion. | |||
=See also= | =See also= | ||
Revision as of 22:00, 23 February 2010
Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.
| New permissions evaluation | |
|---|---|
| Project state | Implementation (patch in tracker) |
| Tracker issue | MDL-21710 |
| Discussion | n/a |
| Assignee | Petr Škoda (škoďák) |
Moodle 2.0
Goals
The main goals are:
- 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)
- 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
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 major source of confusion.
