Override permissions: Difference between revisions

From MoodleDocs
(updated screenshot)
m (Spaces)
 
(4 intermediate revisions by 3 users not shown)
Line 7: Line 7:


==Permissions==
==Permissions==
[[Image:permissionsJS.png|thumb|]]
[[File:override permissions.png|thumb|Override permissions with overridden permission highlighted]]
There are four settings for each permission capability:
There are four settings for each permission capability:


Line 20: Line 20:


;Prohibit
;Prohibit
:This is rarely needed, but occasionally you might want to completely deny permissions to a role in a way that can NOT be overridden at any lower context. An example of when you might need this is when an admin wants to prohibit one person from starting new discussions in any forum on the whole system. In this case they can create a role with that capability set to "Prohibit" and then assign it to that user in the system context.
:This is rarely needed, but occasionally you might want to completely deny permissions to a role in a way that can NOT be overridden at any lower context or by another role. An example of when you might need this is when an admin wants to prohibit one person from starting new discussions in any forum on the whole system. In this case they can create a role with that capability set to "Prohibit" and then assign it to that user in the system context.


==Conflict resolution of permissions==
==Conflict resolution of permissions==
Line 26: Line 26:
Permissions at a "lower" context will generally override anything at a "higher" context (this applies to overrides and assigned roles). The exception is PROHIBIT which can not be overridden at lower levels.
Permissions at a "lower" context will generally override anything at a "higher" context (this applies to overrides and assigned roles). The exception is PROHIBIT which can not be overridden at lower levels.


If two roles are assigned to a person in any context, one with ALLOW and one with PREVENT, then ALLOW will win.
If two roles are assigned to a person in the same context, and for a particular permission one role has ALLOW and one has PREVENT, then ALLOW will win.


===Special exceptions===
===Special exceptions===


Note that the guest user account will generally be prevented from posting content (eg forums, calendar entries, blogs) even if it is given the capability to do so.
Note that the guest user account will generally be prevented from posting content (e.g. forums, calendar entries, blogs) even if it is given the capability to do so.


==Locations for overriding permissions==
==Locations for overriding permissions==


*Front page context: ''Administration > Front Page settings > Users > Permissions''
*Front page context: ''Administration > Front Page settings > Users > Permissions''
*Course category context (when used):''Category > Administration > Permissions''  
*Course category context (when used): ''Category > Administration > Permissions''  
*Course context: ''Administration > Course administration > Users > Permissions''  
*Course context: ''Administration > Course administration > Users > Permissions''  
*Module context: (from the chosen module) ''Administration > Module administration > Permissions''
*Module context: (from the chosen module) ''Administration > Module administration > Permissions''
Line 61: Line 61:


==Overriding permissions for selected students==
==Overriding permissions for selected students==
Sometimes a teacher will want to over ride permissions for selected students. Typically they will assign a student a role locally. For example, assign a student as a non-editing teacher.  However, managers can override specific permission in a role.  This does not create a new role. It modifies an existing specific role and affects all users assigned to that role in the context.  
Sometimes a teacher will want to override permissions for selected students. Typically they will assign a student a role locally. For example, assign a student as a non-editing teacher.  However, managers can override specific permission in a role.  This does not create a new role. It modifies an existing specific role and affects all users assigned to that role in the context.  


Sometimes the administrator (or someone with the permissions to) will create a new role.  For example, the administrator will copy all the student permissions to a new role, then change specific permissions. The teacher then assigns specific students to this role without having to worry about checking off the correct role permissions.
Sometimes the administrator (or someone with the permissions to) will create a new role.  For example, the administrator will copy all the student permissions to a new role, then change specific permissions. The teacher then assigns specific students to this role without having to worry about checking off the correct role permissions.
Line 70: Line 70:


[[es:Anular permisos]]
[[es:Anular permisos]]
[[eu:Baimenak_kendu]]
[[eu:Baimenak kendu]]
[[fr:Définir des dérogations aux rôles]]
[[fr:Définir des dérogations aux rôles]]
[[ja:ロールのオーバーライド]]
[[ja:ロールのオーバーライド]]
[[de:Zugriffsrechte ändern]]
[[de:Zugriffsrechte ändern]]

Latest revision as of 08:47, 29 January 2023


Overrides are specific permissions designed to override a role in a specific context, allowing you to "tweak" your permissions as required.

Overrides may be used to "open up" areas by giving users extra permissions. For example, an override may be used to enable students to rate forum posts (see Forum settings for details).

Overrides may also be used to prevent actions, such as starting new discussions in an archived forum.

Permissions

Override permissions with overridden permission highlighted

There are four settings for each permission capability:

Inherit
The default setting. If a capability is set to inherit, the user's permissions remain the same as they are in a less specific context, or another role where the capability is defined. For example, if a student is allowed to attempt quiz questions at the course level, their role in a specific quiz will inherit this setting. Ultimately, if permission is never allowed at any level, then the user will have no permission for that capability.
Allow
This enables a user to use a capability in a given context. This permission applies for the context that the role gets assigned plus all lower contexts. For example, if a user is assigned the role of student in a course, they will be able to start new discussions in all forums in that course (unless a forum contains an override with a prevent or prohibit value for the capability).
Prevent
By choosing this you are removing permission for this capability (only for this role), even if the users with this role were allowed that permission in a higher context. If any other role allows the same capability, even for a higher or lower context, this prevent will have no effect.
Prohibit
This is rarely needed, but occasionally you might want to completely deny permissions to a role in a way that can NOT be overridden at any lower context or by another role. An example of when you might need this is when an admin wants to prohibit one person from starting new discussions in any forum on the whole system. In this case they can create a role with that capability set to "Prohibit" and then assign it to that user in the system context.

Conflict resolution of permissions

Permissions at a "lower" context will generally override anything at a "higher" context (this applies to overrides and assigned roles). The exception is PROHIBIT which can not be overridden at lower levels.

If two roles are assigned to a person in the same context, and for a particular permission one role has ALLOW and one has PREVENT, then ALLOW will win.

Special exceptions

Note that the guest user account will generally be prevented from posting content (e.g. forums, calendar entries, blogs) even if it is given the capability to do so.

Locations for overriding permissions

  • Front page context: Administration > Front Page settings > Users > Permissions
  • Course category context (when used): Category > Administration > Permissions
  • Course context: Administration > Course administration > Users > Permissions
  • Module context: (from the chosen module) Administration > Module administration > Permissions
  • Block context: (from the chosen block) Administration > Block administration > Permissions
  • User context: (from the user's profile) Administration > Roles > Permissions

Ability to override permissions

Users who have the capability moodle/role:override allowed or the capability moodle/role:safeoverride allowed) can override permissions for selected roles (as set in Allow role overrides).

The default manager role has the capability moodle/role:override allowed, and can override permissions for all other roles.

The default teacher role has the capability moodle/role:safeoverride allowed, and can override permissions for the roles of non-editing teacher, student and guest.

Enabling non-editing teachers to override safe permissions

  1. Access Administration > Site Administration > Users > Permissions > Define roles.
  2. Edit the non-editing teacher role and change the capability Capabilities/moodle/role:safeoverride to allow.
  3. Click the button "Save changes".
  4. Click the tab "Allow role overrides" (in Administration > Site administration > Users > Permissions > Define roles).
  5. Check the appropriate box(s) in the non-editing teacher row to set which role(s) they can override. Most likely it will just be the student role (you don't want non-editing teachers to be able to override managers), so check the box where the non-editing teacher row intersects with the student column.
  6. Click the button "Save changes".

If preferred, a new role for overriding permissions may be created and selected non-editing teachers assigned to it.

Overriding permissions for selected students

Sometimes a teacher will want to override permissions for selected students. Typically they will assign a student a role locally. For example, assign a student as a non-editing teacher. However, managers can override specific permission in a role. This does not create a new role. It modifies an existing specific role and affects all users assigned to that role in the context.

Sometimes the administrator (or someone with the permissions to) will create a new role. For example, the administrator will copy all the student permissions to a new role, then change specific permissions. The teacher then assigns specific students to this role without having to worry about checking off the correct role permissions.

See also