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
(→‎Example roles: demo teacher role link)
(legacy role types)
Line 13: Line 13:


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


==Permissions==
==Permissions==
Line 36: Line 37:
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).  
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 role types==


* Legacy capabilities were implemented for backward compatibility.
* Legacy role types 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.
* Selecting a legacy role type in 1.8 (or allowing a legacy capability in 1.7) 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.
*It is recommended that a legacy role type is selected only for roles that are similar to pre-Moodle 1.7 student/teacher/admin/creator roles.  
* It is not necessary to select a legacy role type unless using old 3rd party code that was not designed for Moodle 1.7 and doesn't yet support roles.


==Adding a new role==
==Adding a new role==

Revision as of 12:39, 9 May 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 role types

  • Legacy role types were implemented for backward compatibility.
  • Selecting a legacy role type in 1.8 (or allowing a legacy capability in 1.7) does NOT provide a new role with all capabilities of a pre-Moodle 1.7 role.
  • It is recommended that a legacy role type is selected only for roles that are similar to pre-Moodle 1.7 student/teacher/admin/creator roles.
  • It is not necessary to select a legacy role type 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
  • Demo teacher - for providing a demonstration teacher account with a password which can't be changed

See also