What is the difference between setting a capability to Inherit and Prevent at site level?
Since site level is the highest context, I wonder what does it inherit form.
I have the same two questions. Actually, I would modify your first question:
For example, Administrator has some capabilities marked Inherit and others marked Allow. If an Admin can "do anything," why aren't they all marked as Allow? Or, if we assume an imaginary god-like can-do-anything role that is the basis for all other system-level roles, why not mark all of Admin's capabilities as Inherit?
What is the difference between setting a capability to Inherit and Allow at site level?
since it's pretty clear that Prevent ignores higher-level contexts, if any.For example, Administrator has some capabilities marked Inherit and others marked Allow. If an Admin can "do anything," why aren't they all marked as Allow? Or, if we assume an imaginary god-like can-do-anything role that is the basis for all other system-level roles, why not mark all of Admin's capabilities as Inherit?
Interesting, yes... The global admin role has a default capability for "View courses" as "Inherit". I too wonder why? Even if this is meant as "Not set", the why is it not set?
Yes, "View courses" is interesting. 
Users with this capability allowed are listed as course participants (unless the role is a hidden assignment). As we don't want admins to be listed as course participants, it's not set.
Users with this capability allowed are listed as course participants (unless the role is a hidden assignment). As we don't want admins to be listed as course participants, it's not set.
Ok, a bit if a hack there 
But, where do they get the permission/capability to view courses anyway? (I'm lazy and doing my digital signal processing homework on the side so I didn't look at the code)
Edit: If it's the "Allowed to do everything", then couldn't everything else be "Not set" but that?
Edit: If it's the "Allowed to do everything", then couldn't everything else be "Not set" but that?
Hi,
Please note that the word "Inherit" on the define roles page has been changed to "Not set" to hopefully make things easier to understand.
Regarding admin capabilities, most are set to Allow. A few capabilities relating to activity participation e.g. assignment submission are not set.
Please note that the word "Inherit" on the define roles page has been changed to "Not set" to hopefully make things easier to understand.
Regarding admin capabilities, most are set to Allow. A few capabilities relating to activity participation e.g. assignment submission are not set.
Regarding admin capabilities, most are set to Allow
If they were all set to Allow, it would make sense. However some Admin capabilities are set to Inherit (a.k.a. Not set), which suggests the existence of a higher-level role. This is what we find confusing!
Our confusion deepens when we look at Teacher's capabilities. Most Teacher capabilities are set to Inherit (a.k.a. Not set). Inherit from what?
If they were all set to Allow, it would make sense. However some Admin capabilities are set to Inherit (a.k.a. Not set), which suggests the existence of a higher-level role. This is what we find confusing!
Our confusion deepens when we look at Teacher's capabilities. Most Teacher capabilities are set to Inherit (a.k.a. Not set). Inherit from what?
hmm, most of Teacher capabilities are actually set to Allow.
And then, for those things that usually are not applicable to such role, they are set to Not Set.
John, do you have the most recent 1.8?
Even that small change in language was worth it Inherit was way too confusing.
And then, for those things that usually are not applicable to such role, they are set to Not Set.
John, do you have the most recent 1.8?
Even that small change in language was worth it
I have the very latest stable version of 1.8. Oops, you are right -- most Teacher capabilities are set to Allow. However quite a few are Not set. As long as even one is "Not set" I will be confused because I do not know what "Not set" means.
The documentation says:
This goes back to the original question at the beginning of the forum. When you're a System-level role, what permission did you "already have?"
What exactly does "Not set" mean?
The documentation says:
Inherit. This is the default setting, generally. It's a neutral setting that means "use whatever setting the user already had". If a role gets assigned to someone (e.g. in a course) that has this permission for a capability, then the actual permission they'll have will just be the same as they already had at higher-level contexts (e.g. categories or site level). Ultimately, if permission is never allowed at any level, then the user will have no permission for that capability.
This goes back to the original question at the beginning of the forum. When you're a System-level role, what permission did you "already have?"
What exactly does "Not set" mean?
Documentation needs to be updated, that's for sure. I have updated that Inherit word, and I will try to think on the definition
Hi all, thanks for your consideration. I raised this question since I found that in some download modules, most of the capabilities are set to 'Inherit' (a.k.a. Not Set) from the site context down to the module context. In my experience, with this settings, the outcome is same as PREVENT.
As what John asked, What exactly does "Not set" mean?
I can explain what Not set means!
Say a role is assigned to a user in in a course context, and the role has permission 'Not set' for some capability. Then the actual permission they'll have in this context will be the same as what they have in the category context, or failing that, in the site context.
Determining whether a 'Not set' permission is Allowed requires Moodle to search up through the context chain (see below). Ultimately, if the permission is never allowed at any level, it becomes 'Prevent.'
The context chain:
Say a role is assigned to a user in in a course context, and the role has permission 'Not set' for some capability. Then the actual permission they'll have in this context will be the same as what they have in the category context, or failing that, in the site context.
The context chain:
- Site (System)
- Course Categories
- Course Sub-categories
- Courses
- Blocks and Activities
I also updated the Permissions documentation.