Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Manage roles.

Manage roles: Difference between revisions

From MoodleDocs
mNo edit summary
(simplifying, copying permissions text from help file)
Line 1: Line 1:
{{Roles}}
{{Roles}}
{{Moodle 1.7}}
Location: ''Administration > Users > Permissions > Define roles''
Location: ''Administration > Users > Permissions > Define roles''
From Moodle 1.7 onwards administrators may choose to add or edit roles.
==Predefined roles==


Moodle comes with 7 predefined roles:
Moodle comes with 7 predefined roles:
Line 16: Line 10:
*[[Student]]
*[[Student]]
*[[Guest access|Guest]]
*[[Guest access|Guest]]
*Authenticated user (1.8)
*Authenticated user (from 1.8 onwards)


Each role may be edited via the link next to its name.
Each role may be edited via the link next to its name.
{{Moodle 1.8}}
Role permissions may be reset or a duplicate role created using the buttons at the top of the View role details page (from Moodle 1.8 onwards).


==Permissions==
==Permissions==
The permissions matrix allows a very granular approach to assigning rights to a role (a class of users).  Assigning or editing permissions should be done with great care.  A change can produce a profound unwanted effect, or an annoying effect that will be hard to understand the cause.
There are over 150 lines of capabilities where any of 4 different permissions can be assigned.  The capabilities are grouped in 21 categories.
[[Image:Roles_Define_Permissions_crop.JPG|frame|center|Top of the permissions table]]


The permissions for each of the pre-defined roles are shown with a grey background (from Moodle 1.8 onwards).
Permissions are settings for specific capabilities. There are four values:


===Permission terms===
;Inherit
From lowest to highest, from general to specific.
: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.  


*Inherit - pass along from before [lowest level, always loses]
;Allow
*Allow - let happen or permit [same level as prevent]
:By choosing this you are granting permission for this capability to people who are assigned this role. This permission applies for the context that this role gets assigned plus all "lower" contexts. For example, if this role is a student role assigned to a course, then students will be able to "start new discussions" in all forums in that course, unless some forum contains an override or a new assignment with a Prevent or Prohibit value for this capability.
*Prevent - stop [same level as allow]
*Prohibit - forbid [highest level, always wins]


===Permission examples===
;Prevent
'''Inherit''': if no permission is defined, then the capability permission is inherited from a context that is more general than the current context.  
:By choosing this you are removing permission for this capability, even if the users with this role were allowed that permission in a higher context.


'''Allow and prevent''' will cancel each other out if set for the same capability at the same context level. If this happens, we refer to the previous context level to determine the permission for the capability.
;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 site. In this case they can create a role with that capability set to "Prohibit" and then assign it to that user in the site context.  


'''Prohibit''': If we set prohibit on a capability, it means that the capability cannot be overridden. Prohibit always wins and creates a permanent stop.  
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.


Since the capabilities in each role could be different and participants can be assigned different roles, there could be a conflict in capabilities. The hierarchy of permissions  resolves this by saying that the capability defined for a more specific context will win, unless an prohibit is encountered in a less specific context.  
If two roles are assigned to a person in the same context, one with Allow and one with Prevent, which one wins? In this case, Moodle will look up the context tree for a "decider".


Example 1. Mark has a student role in Course One, which allows all students to write into the wikis "Everyone" and "Homework". But Mark also got assigned a Visitor role at a module context level (for the wiki "Honors") and Visitors are prevented writing in the Honors wiki.  Thus Mark can write into the "Everyone" and "Homework" wikis but not in "Honors".
For example, a student has two roles in a course, one that allows them to start new discussions, one that prevents them. In this case, we check the categories and the site contexts, looking for another defined permission to help us decide. If we don't find one, then permission is Prevent by default (because the two settings cancelled each other out, and thus they have no permission).  
 
Example 2. Jeff has been assigned to a "naughty student" role that prohibits him from postings in any forums for the whole site. However his teacher assigned him a "facilitator" role in "Science forum" in the course Science and Math 101. Since a higher context prohibit permission always wins, Jeff is unable to post in "Science forum".


==Legacy capabilities==
==Legacy capabilities==
Line 76: Line 61:


==See also==
==See also==
*The capability [[Capabilities/moodle/role:manage|moodle/role:manage]]
 
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=57812 Create a Parent of a student role] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=66782 What happens if a user has multiple roles in a course?] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=66782 What happens if a user has multiple roles in a course?] forum discussion



Revision as of 15:00, 29 March 2007


Location: Administration > Users > Permissions > Define roles

Moodle comes with 7 predefined roles:

Each role may be edited via the link next to its name.

Permissions

Permissions are settings for specific capabilities. There are four values:

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.
Allow
By choosing this you are granting permission for this capability to people who are assigned this role. This permission applies for the context that this role gets assigned plus all "lower" contexts. For example, if this role is a student role assigned to a course, then students will be able to "start new discussions" in all forums in that course, unless some forum contains an override or a new assignment with a Prevent or Prohibit value for this capability.
Prevent
By choosing this you are removing permission for this capability, even if the users with this role were allowed that permission in a higher context.
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 site. In this case they can create a role with that capability set to "Prohibit" and then assign it to that user in the site context.

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, one with Allow and one with Prevent, which one wins? In this case, Moodle will look up the context tree for a "decider".

For example, a student has two roles in a course, one that allows them to start new discussions, one that prevents them. In this case, we check the categories and the site contexts, looking for another defined permission to help us decide. If we don't find one, then permission is Prevent by default (because the two settings cancelled each other out, and thus they have no permission).

Legacy capabilities

  • Legacy capabilities were implemented for backward compatibility.
  • Allowing a legacy capability does NOT provide a new role with all capabilities of a pre-Moodle 1.7 role.
  • It is not necessary to allow any legacy capabilities unless using old 3rd party code that was not designed for Moodle 1.7 and doesn't yet support roles.

Adding a new role

  1. Give the role an appropriate name. If you need to name the role for multiple languages you can use multi-lang syntax if you wish, such as <span lang="en" class="multilang">Teacher</span> <span lang="es_es" class="multilang">Profesor</span>. If multi-lang syntax is used then Filter all strings should be set in Filter settings.
  2. Give the role a meaningful short name. The short name is necessary for other plugins in Moodle that may need to refer to the role (e.g. when uploading users from a file or setting enrolments via an enrolment plugin).
  3. Optional: Give the role a description so that everyone has a common understanding of it.

Testing a new role

  1. Create test user and assign new role to them.
  2. Either logout as admin and then login as test user or use a different browser to login as test user.

Note: New roles may not be tested using the "Switch role to..." feature.

Example roles

  • Inspector - for providing external inspectors with permission to view all courses (without being required to enrol)
  • Parent - for providing parents/mentors/tutors with permission to view certain information about their children/mentees/tutees

See also