Note: You are currently viewing documentation for Moodle 3.6. Up-to-date documentation for the latest stable version of Moodle is likely available here: New permissions evaluation in 2.0.

Development:New permissions evaluation in 2.0: Difference between revisions

From MoodleDocs
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Infobox Project
{{Infobox Project
|name = New permissions evaluation
|name = New permissions evaluation
|state = Implementated
|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=
Line 28: Line 28:


=See also=
=See also=
* [[Development:Enrolment rewrite and role tweaks proposal]]
* [[Obsolete:Enrolment rewrite and role tweaks proposal]]
* [[Development:Role overrides revisited]]
* [[Obsolete:Role overrides revisited]]
* [[Development:New permission overriding UI]]
* [[Development:New permission overriding UI]]
* [[Development:Role archetypes]]
* [[Development:Role archetypes]]


[[Category:Developer]]
[[Category:Roles]]
[[Category:Roles]]

Latest revision as of 19:06, 15 June 2010

Template:Infobox Project

Template:Moodle 2.0


Goals

The main goals are:

  1. replace current confusing permission evaluation
  2. improve performance
  3. enable improvements in permission overriding UI

Permission evaluation algorithm

  1. find all roles with given capability used in definition or override
  2. 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)
  3. 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 major source of confusion.

See also