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
No edit summary
(role archetypes)
 
(75 intermediate revisions by 16 users not shown)
Line 1: Line 1:
{{Roles}}
{{Roles}}
{{Moodle 1.7}}
Location: ''Administration > Users > Permissions > Define roles''
Moodle 1.7 allows the administrator to add or edit existing roles available on the Moodle site. This is done through the Administration block>>User>>Permission>>Define roles menu area.  Remember that Moodle comes with 7 default roles and adding and editing roles is completely optional.


==Define roles==
There are 3 tabs on the define role page.
[[Image:Roles_Define_tab.JPG|center]]


*Manage roles - The place to add and define permissions for a new role, or edit name and/or permissions associated with existing Moodle roles.
The define roles page has three tabs, for managing roles, [[Allow role assignments|allowing role assignments]] and [[Allow role overrides|allowing role overrides]].
*[[Allow role assignments]] - A matrix which determines which role can assign users to other roles.
 
*[[Allow role overrides]] - A matrix which determines which role can override a previously assigned role. The default is that only an administrator can override any role assigned by another role.
The manage roles tab contains a list of roles on your site. The edit column contains icons for editing and deleting roles, and for moving them up or down in the list (affecting the way that roles are listed around Moodle).
 
 
==Predefined roles==
Moodle comes with 7 predefined roles:
*[[Administrator role|Administrator]]
*[[Course creator role|Course creator]]
*[[Teacher role|Teacher]]
*[[Teacher role| Non-editing teacher]]
*[[Student role|Student]]
*[[Guest role|Guest]]
*[[Authenticated user role|Authenticated user]] (from 1.8 onwards)
 
==Editing a role==
[[Image:manage roles.png|thumb|Managing roles]]
To edit a role:
#Click on Permissions in the Site Administration block, then Define roles.
#Click the edit icon opposite the role you want to edit e.g. student.
#On the edit role page, change permissions as required.
#Scroll to the bottom of the page and click the "Save changes" button.
 
==Adding a new role==
 
To add a new role:
#Click on Permissions in the Site Administration block, then Define roles.
#Click the "Add a new role" button.
#On the add a new role page, give the role a name. If you need to name the role for multiple languages you can use [[Multi language content|multi-lang syntax]] if you wish, such as <code><nowiki><span lang="en" class="multilang">Teacher</span> <span lang="es_es" class="multilang">Profesor</span></nowiki></code>. If multi-lang syntax is used then ''Filter all strings'' should be set in [[Filter settings]].
#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).
#Give the role a description (optional).
#Set permissions as required.
#Scroll to the bottom of the page and click the "Add a new role" button.
 
==Creating a duplicate role==
In Moodle 1.8 onwards, a new role may be quickly created by making a copy of an existing role.
 
To create a duplicate role:
#Click on Permissions in the Site Administration block, then Define roles.
#Click on the role to be duplicated, for example "Guest".
#Click the "Duplicate role" button near the top of the "View role details" page.
#Answer Yes to the question "Are you sure you want to duplicate the role ...?"
#The list of roles will now show the "... copy 1" at the bottom, for example "Guest copy 1". 
#Edit the duplicated role to meet your needs.


==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 catagories. We strongly recommend not to change the LEGACY roles. Here is the top of the list.
There are four settings for each capability:
 
;Not Set
:This is the default value for all permissions when a new role is created.
 
:Note that if a capability is left as "Not Set," the resulting behavior is that of '''Prevent''', unless otherwise allowed by another role at a higher context. For example, if you mark Not Set for the permission of a Student to Add New Discussions in a forum, they will not be allowed to do so unless they also hold the role of Teacher, Course Creator, or another higher role for which that capability ''is'' allowed.
 
;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 system context.
 
==Legacy role types==
 
Legacy role types in Moodle 1.7 to 1.9 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.
 
==Role archetypes==
 
{{Moodle 2.0}}In Moodle 2.0 onwards, a role archetype may be set. If the role is then reset to default, appropriate permissions are set. Thus it provides an alternative method to creating a duplicate of a default role.
 
If new capabilities are added in future versions of Moodle, the role archetype setting determines any new permissions for the role when the site is upgraded.


[[Image:Roles_Define_Permissions_crop.JPG|center]]
==New role considerations==


===Permission terms===
A newly-created role does not have the ability to assign or override any other roles. This is true even when the new role is a copy of a role that had such abilities.  If such ability is needed, the administrator must grant it explicitly (Site administration -> Users -> Permissions -> Define roles ->  Allow role assignments and Allow role overrides tab).
From lowest to highest, from general to specific.


*Inherit - pass along from before [lowest level, always loses]
A new role is not automatically listed in course descriptions even if was created by copying a role that is listed, such as [[Teacher]]. If you want the new role to appear in the course listing, you must set it explicitly via ''Administration > Appearance > [[Course managers]]''.
*Allow - let happen or permit [same level as prevent]
*Prevent - stop [same level as allow]
*Prohibit - forbid {highest level, always wins]


===Permission examples===
==Testing a new role==
'''Inherit''': if no permission is defined, then the capability permission is inherited from a context that is more general than the current 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.
In Moodle 1.9 and later, you can use the "Switch roles to..." menu in the upper right corner of each course page to test the new role.  Since switching roles confines you to those roles you can assign in a course context, this method is only useful for testing course-scoped capabilities (i.e., it will not be useful for testing permissions that apply outside the course context, like moodle/user:edit).


'''Prohibit''': If we set prohibit on a capability, it means that the capability cannot be overridden. Prohibit always wins and creates a permenant stop.  
In Moodle 1.7.x and 1.8.x role changes take effect only after the next login from that user, so new roles may not be tested using the "Switch role to..." feature.


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.  
In any version of Moodle with roles, you can always create test user and assign the new role to themThen logout as admin and login as the test user.


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".
==Example roles==


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".
*[[Inspector role|Inspector]] - for providing external inspectors with permission to view all courses (without being required to enrol)
*[[Parent role|Parent]] - for providing parents/mentors/tutors with permission to view certain information about their children/mentees/tutees
*[[Demo teacher role|Demo teacher]] - for providing a demonstration teacher account with a password which can't be changed
*[[Forum moderator role|Forum moderator]] - for providing a user with permission in a particular forum to edit or delete forum posts, split discussions and move discussions to other forums
*[[Calendar editor role|Calendar editor]] - for enabling a user to add site or course events to the calendar
*[[Blogger role|Blogger]] - for limiting blogging to specific users only
*[[Quiz user with unlimited time role|Quiz user with unlimited time]] - for allowing a user unlimited time to attempt a quiz which has a time limit set
*[[Question creator role|Question creator]] - for enabling students to create questions for use in quizzes
*[[Keyholder role]] - someone who manages the [[Enrolment key]] in courses
*[[Course requester role]] - for restricting users who can make course requests


==Examples of roles==
==See also==
Why would a site want different roles?  Consider
{|  border="0" cellpadding="2"
!width="200"|
!width="200"|
!width="200"|
|-
||*Site Designers||*Educational Authority Adviser||*Educational Inspector||
|-
||*Second Marker / Moderator||*Peer observer of teaching||*External Examiner
|-
||*Parent||*Manager||*Weekly Seminar Leader
|-
||*Mentor/Mentee||*Community-Designed Rating Criteria||*Visitor
|-
||*Guest Speaker||*Former Student||*Alumnus
|-
||*Librarian||*Teacher||*Community Education Tutors/Trainers
|-
||*Secretary/Student Worker||*Teaching Assistant||*Student - FERPA rights
|-
||*Help Desk|| ||
|}


==Enrolling existing students in a course ==
* [[How permissions are calculated ]]
This has changed by comparison with how it worked in Moodle 1.6, and is now part of the roles system. Go to your course, in the Administration box, click Assign Roles, when the new page opens, click on Students and you will be presented with a screen similar to the one available in Moodle 1.6
* [[The rolesdebug.php roles debugging script]] (a contributed script)
* [[Useful things a teacher can do with roles]]


==Basic concept definitions==
Using Moodle forum discussions:


*A '''role''' is an identifier of the user's status in some context. For example, teacher, student and forum moderator are examples of roles.
* [http://moodle.org/mod/forum/discuss.php?d=66782 What happens if a user has multiple roles in a course?]
*A '''capability''' is a description of some particular Moodle feature. Capabilities are associated with roles. For example, being able to reply to a forum post is a capability.
* [http://moodle.org/mod/forum/discuss.php?d=90140 logged in: what role am I?]
*A '''permission''' is some value that is assigned for a capability for a particular role. For example, using the prevent permission to limit all students from posting to any forum.
*A '''context''' is a "space" in the Moodle, such as courses, activity modules, blocks, forums etc.
*A '''hierarchy of permissions''' determines which permission wins or is going to be in effect if there is an apparent conflict.  For example, the site allow all students the permission to  to post in forums, but a teacher might prevent that right in a particular course.  The hieracary of permissions would allow a student to post in one course but not in another course.


[[Category: Administrator]]
[[Category:Administrator]]
[[Category:Roles]]


[[es:Gestionar_roles]]
[[eu:Rolak_kudeatu]]
[[fr:Définir les rôles]]
[[fr:Définir les rôles]]
[[ja:ロールの管理]]
[[de:Rollen verwalten]]

Latest revision as of 14:27, 8 November 2010


Location: Administration > Users > Permissions > Define roles


The define roles page has three tabs, for managing roles, allowing role assignments and allowing role overrides.

The manage roles tab contains a list of roles on your site. The edit column contains icons for editing and deleting roles, and for moving them up or down in the list (affecting the way that roles are listed around Moodle).


Predefined roles

Moodle comes with 7 predefined roles:

Editing a role

Managing roles

To edit a role:

  1. Click on Permissions in the Site Administration block, then Define roles.
  2. Click the edit icon opposite the role you want to edit e.g. student.
  3. On the edit role page, change permissions as required.
  4. Scroll to the bottom of the page and click the "Save changes" button.

Adding a new role

To add a new role:

  1. Click on Permissions in the Site Administration block, then Define roles.
  2. Click the "Add a new role" button.
  3. On the add a new role page, give the role a 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.
  4. 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).
  5. Give the role a description (optional).
  6. Set permissions as required.
  7. Scroll to the bottom of the page and click the "Add a new role" button.

Creating a duplicate role

In Moodle 1.8 onwards, a new role may be quickly created by making a copy of an existing role.

To create a duplicate role:

  1. Click on Permissions in the Site Administration block, then Define roles.
  2. Click on the role to be duplicated, for example "Guest".
  3. Click the "Duplicate role" button near the top of the "View role details" page.
  4. Answer Yes to the question "Are you sure you want to duplicate the role ...?"
  5. The list of roles will now show the "... copy 1" at the bottom, for example "Guest copy 1".
  6. Edit the duplicated role to meet your needs.

Permissions

There are four settings for each capability:

Not Set
This is the default value for all permissions when a new role is created.
Note that if a capability is left as "Not Set," the resulting behavior is that of Prevent, unless otherwise allowed by another role at a higher context. For example, if you mark Not Set for the permission of a Student to Add New Discussions in a forum, they will not be allowed to do so unless they also hold the role of Teacher, Course Creator, or another higher role for which that capability is allowed.
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 system context.

Legacy role types

Legacy role types in Moodle 1.7 to 1.9 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.

Role archetypes

Moodle 2.0

In Moodle 2.0 onwards, a role archetype may be set. If the role is then reset to default, appropriate permissions are set. Thus it provides an alternative method to creating a duplicate of a default role.

If new capabilities are added in future versions of Moodle, the role archetype setting determines any new permissions for the role when the site is upgraded.

New role considerations

A newly-created role does not have the ability to assign or override any other roles. This is true even when the new role is a copy of a role that had such abilities. If such ability is needed, the administrator must grant it explicitly (Site administration -> Users -> Permissions -> Define roles -> Allow role assignments and Allow role overrides tab).

A new role is not automatically listed in course descriptions even if was created by copying a role that is listed, such as Teacher. If you want the new role to appear in the course listing, you must set it explicitly via Administration > Appearance > Course managers.

Testing a new role

In Moodle 1.9 and later, you can use the "Switch roles to..." menu in the upper right corner of each course page to test the new role. Since switching roles confines you to those roles you can assign in a course context, this method is only useful for testing course-scoped capabilities (i.e., it will not be useful for testing permissions that apply outside the course context, like moodle/user:edit).

In Moodle 1.7.x and 1.8.x role changes take effect only after the next login from that user, so new roles may not be tested using the "Switch role to..." feature.

In any version of Moodle with roles, you can always create test user and assign the new role to them. Then logout as admin and login as the test user.

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
  • Forum moderator - for providing a user with permission in a particular forum to edit or delete forum posts, split discussions and move discussions to other forums
  • Calendar editor - for enabling a user to add site or course events to the calendar
  • Blogger - for limiting blogging to specific users only
  • Quiz user with unlimited time - for allowing a user unlimited time to attempt a quiz which has a time limit set
  • Question creator - for enabling students to create questions for use in quizzes
  • Keyholder role - someone who manages the Enrolment key in courses
  • Course requester role - for restricting users who can make course requests

See also

Using Moodle forum discussions: