Is my mental model of permissions correct?

Is my mental model of permissions correct?

by N. N. -
Number of replies: 1

Hello,

I've been trying to wrap my head around the permissions model in Moodle. I've gone through the docs but to be honest, I found a lot of ambiguity there. I'm looking to create a concise yet generalized mental model of Moodle permissions.

Piecing together different bits of the docs as well as 3rd party sources, I've come up with the following mental model. But I feel like for all I know, I could be way off... Could anyone please let me know if my understanding of Moodle roles & permissions is wrong?

If you find this post too long, just read (1) please.


(1) Model

I consider that each permission setting has a "score:"

Not Set = inherit setting from the closest role assigned in a broader context, starting with parent context, all the way up to any System roles the user has.

Allow = +1

Prevent = 0

Prohibit = -infinity


The capability is allowed if Score > 0. The capability is not allowed if Score <= 0.

So basically, I understand it as an affirmative system ("glass half full") where the default state of nothingness is restricted, and upon which you explicitly allow things to happen. Prevent isn't really prevent, it's more like "nothing" as opposed to allowing.


(2) Examples:

For a given permission X, and a user viewing a course page who has 2 simultaneous roles, Authenticated User (System context) and Student (Course context)... If each aforementioned role has the following values for Permission X:

  • Authenticated User: Not Set && Student: Not Set => score = 0 => not allowed

  • Authenticated User: Not Set && Student: Allow => score = 1 => allowed

  • Authenticated User: Not Set && Student: Prevent => score = 0 => not allowed

  • Authenticated User: Prevent && Student: Allow => score = 1 => allowed

  • Authenticated User: Allow && Student: Prevent => score = 1 => allowed

  • Authenticated User: Prevent && Student: Not Set => score = 0 => not allowed

  • Authenticated User: Allow && Student: Prevent => score = 1 => allowed

  • Authenticated User: Prevent && Student: Prevent => score = 0 => not allowed


(3) Overrides can be used in order to add or remove one of the roles in a specific context, thus altering the score


(4) Questions

- Is the system really summative? What if the user has 3 roles, does the above score model apply?

Take the example above, except now the user also has a Category-level role, Teacher. Are the following scenarios correct?

  • Authenticated User: Not Set && Teacher: Not Set && Student: Not Set => score = 0 => not allowed

  • Authenticated User: Allow && Teacher: Prevent && Student: Prevent => score = 1 => allowed

  • Authenticated User: Prevent && Teacher: Not Set && Student: Not Set => score = 0 => not allowed

  • Authenticated User: Not Set && Teacher: Prevent && Student: Not Set => score = 0 => not allowed


- If the user has multiple roles in the same context, does the score system still work?

According to (2) in this part of the docs, adding a new System role with Prevent seems to overrule Authenticated User: Allow. Can anyone explain this to me? I thought Allow had priority over Prevent, all other things equal.


How far off am I in my understanding of Moodle's permissions? Thanks in advance.

Average of ratings: -
In reply to N. N.

Re: Is my mental model of permissions correct?

by N. N. -

After conducting some tests, I've realized the following:

• It seems the docs here are wrong: https://docs.moodle.org/31/en/Roles_FAQ#How_can_I_prevent_a_user_from_changing_their_own_password.3F

For any given permission, for a user having 'Allow' on Authenticated User (System context), and 'Prevent' on another System role, 'Allow' should win. Suggestion #2 in the section I linked doesn't work; it should be 'Prohibit' if you want to overrule the 'Allow' from Authenticated User, not 'Prevent' as 'Prevent' loses to 'Allow'. Context doesn't matter at all as any 'Allow' anywhere defeats any 'Prevents' anywhere.


• This bit in the docs also seems wrong: "Permissions at a "lower" context will generally override anything at a "higher" context (this applies to overrides and assigned roles)."

It's only true for manual overrides.

For assigned roles, 'Allow' always defeats 'Prevent' and 'Not Set,' except if there's a 'Prohibit.' This seems to be completely unaffected by context. If for a given permission, a user's role has 'Prevent' on all contexts except for 1 'Allow,' then the 'Allow' will win - it doesn't matter at all which context has the 'Prevent' and which has the 'Allow.'


• It also appears that 'Not Set' behaves 100% the same way as 'Prevent.' I thought the idea of 'Not Set' was to inherit permissions from the larger scope - but when you think about it, it turns out there is never something to inherit. A user having at least 1 'Allow' in any context will always result in 'Allow,' even if there's a 'Not Set' or 'Prevent' in any other context. The only exception is if there's a 'Prohibit' in any of the user's roles, in any context - then the 'Prohibit' wins.

Can anyone explain to me why 'Not Set' exists?


__

Am I taking crazy pills, or are the docs completely inconsistent when it comes to roles & permissions?

Average of ratings: -