Difference between revisions of "Roles and permissions"

Jump to: navigation, search

Note: You are currently viewing documentation for Moodle 2.3. Up-to-date documentation for the latest stable version is available here: Roles and permissions.

(Contexts)
(simplifying, transferring content to other pages)
Line 1: Line 1:
 
{{Roles}}
 
{{Roles}}
 
{{Moodle 1.7}}
 
{{Moodle 1.7}}
The new roles and capabilities system in Moodle provides you with a huge amount of flexibility to manage how students and other people interact. In older versions of Moode (prior to 1.7), there were only six roles possible: guest, student, non-editing teacher, editing teacher, course creator, and administrator. Whilst the new system supports these roles out of the box, it also allows you to create and customize roles, and to change what a given role can do in each activity. For example, you can now create permissions in individual forums, which allows you to let students act as moderators in one forum, while you retain the moderator role in all of the other forums in your course.
+
Roles and capabilities in Moodle 1.7 onwards provides great flexibility in managing how users interact. Prior to Moodle 1.7, there were only six roles possible: guest, student, non-editing teacher, editing teacher, course creator, and administrator. Whilst these roles may still be used, it's now possible to create additional roles, and to change what a given role can do in a particular activity.
 
 
==Examples of roles==
 
Why would a site want different roles?  Consider the following:
 
 
 
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
 
  
 
==Definitions==
 
==Definitions==
*A '''role''' is an identifier of the user's status in some context, for example ''teacher'', ''student'' and ''forum moderator''.
+
;Role
*A '''capability''' is a description of a particular Moodle feature, for example ''[[Capabilities/moodle/blog:create|moodle/blog:create]]''. Capabilities are associated with roles.
+
:An identifier of the user's status in some context, for example ''teacher'', ''student'' and ''forum moderator''
*A '''permission''' is [[Manage roles#Permissions|a value that is assigned]] for a capability for a particular role, for example ''allow'' or ''prevent''.
+
;Capability
*A '''context''' is a "space" in Moodle, such as courses, activity modules or blocks. Roles will only work if the role assignment is made at the correct context level. For example, a ''teacher'' role should be assigned at course context level, a ''forum moderator'' for a particular forum should be assigned at activity level, an ''administrator'' should be assigned at system level and so on.
+
:A description of a particular Moodle feature, for example ''[[Capabilities/moodle/blog:create|moodle/blog:create]]''
 +
;Permission
 +
:Some value that is assigned for a capability for a particular role, for example ''allow'' or ''prevent''
 +
;Context
 +
:A "space" in Moodle, such as courses, activity modules or blocks
  
 
==Contexts==
 
==Contexts==
Line 34: Line 33:
  
 
The upgrade to 1.7 is as smooth as we could make it.  The existing roles (admin, teacher, student etc.) and the existing capabilities will be automatically retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, mirroring what we have in 1.6.  With no modifications, Moodle will operate almost exactly the same before and after the upgrade.
 
The upgrade to 1.7 is as smooth as we could make it.  The existing roles (admin, teacher, student etc.) and the existing capabilities will be automatically retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, mirroring what we have in 1.6.  With no modifications, Moodle will operate almost exactly the same before and after the upgrade.
 
==Roles in 1.8==
 
{{Moodle 1.8}}
 
In addition to many Roles fixes and refinements, Moodle 1.8 has separated the SYSTEM context from the SITE context (which makes it more like 1.6 used to work). The SITE context is the "front page course" and it's activities. This should make it easier for admins to set up permissions.
 
  
 
==See also==
 
==See also==
Line 43: Line 38:
 
*[[:Category:Capabilities]]
 
*[[:Category:Capabilities]]
 
*Using Moodle [http://moodle.org/mod/forum/view.php?id=6826 Roles and Capabilities forum]
 
*Using Moodle [http://moodle.org/mod/forum/view.php?id=6826 Roles and Capabilities forum]
*[http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=10221 Roles stuff fixed in 1.8]
 
  
[[Category:Teacher]]
 
[[Category:Administrator]]
 
 
[[Category:Roles]]
 
[[Category:Roles]]
  
 
[[fr:Rôles et capacités]]
 
[[fr:Rôles et capacités]]

Revision as of 13:19, 29 March 2007

Template:Moodle 1.7

Roles and capabilities in Moodle 1.7 onwards provides great flexibility in managing how users interact. Prior to Moodle 1.7, there were only six roles possible: guest, student, non-editing teacher, editing teacher, course creator, and administrator. Whilst these roles may still be used, it's now possible to create additional roles, and to change what a given role can do in a particular activity.

Definitions

Role
An identifier of the user's status in some context, for example teacher, student and forum moderator
Capability
A description of a particular Moodle feature, for example moodle/blog:create
Permission
Some value that is assigned for a capability for a particular role, for example allow or prevent
Context
A "space" in Moodle, such as courses, activity modules or blocks

Contexts

The list of contexts in hierarchical order is as follows:

  • System context - accessible via the administrator's block (no parent)
  • Site context - accessible via the administrator's block front page section (parent = system) 1.8+ only
  • Course category context - accessible via the course category page (parent = site)
  • Course context - accessible via the course administration block (old admin block) (parent = course category or site)
  • Module context - accessible whilst updating the module (parent = course)
  • Block context - accessible when editing mode is on (parent = site or course)
  • User context - accessible via the Roles tab in the user profile (parent = site)

Inheritance will kick in if a role is assigned at a higher level. For example assigning a teacher to a course category will make this user the teacher for ALL courses within the category.

Capabilities

Capabilities are aggregated and controlled via roles. Stated another way, a role consists of a list of capabilities for different possible actions within Moodle (e.g. delete discussions or add activities). With 1.7 it's now possible to have sophisticated yet flexible levels of control over participants and what they can or can't do.

Upgrading to 1.7

The upgrade to 1.7 is as smooth as we could make it. The existing roles (admin, teacher, student etc.) and the existing capabilities will be automatically retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, mirroring what we have in 1.6. With no modifications, Moodle will operate almost exactly the same before and after the upgrade.

See also