Roles and permissions: Difference between revisions
From MoodleDocs
(→Roles) |
Helen Foster (talk | contribs) m (small re-wording and formatting) |
||
| Line 6: | Line 6: | ||
Previous Moodle versions had predefined, fixed roles. There was no easy way to change what a teacher, or student, for instance, could do. While fixed roles are adequate for many users, others require greater flexibility in regulating how users see and interact with the system. | Previous Moodle versions had predefined, fixed roles. There was no easy way to change what a teacher, or student, for instance, could do. While fixed roles are adequate for many users, others require greater flexibility in regulating how users see and interact with the system. | ||
With Roles, authorised users | With Roles, authorised users may [[Manage roles|create]] any number of customised roles and assign them to users. From 1.7, an organisation may create multiple roles so that, for instance, students assigned Role A could post to forums, while students assigned Role B are prevented from posting. | ||
Definitions | ==Definitions== | ||
*A '''role''' is an identifier of the user's status in some context | *A '''role''' is an identifier of the user's status in some context, for example ''teacher'', ''student'' and ''forum moderator''. | ||
*A '''capability''' is a description of | *A '''capability''' is a description of a particular Moodle feature, for example ''[[Capabilities/moodle/blog:create|moodle/blog:create]]''. Capabilities are associated with roles. | ||
*A '''permission''' is [[Manage roles#Permissions|a value that is assigned]] for a capability for a particular role | *A '''permission''' is [[Manage roles#Permissions|a value that is assigned]] for a capability for a particular role, for example ''allow'' or ''prevent''. | ||
*A '''context''' is a "space" in | *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. | ||
==Contexts== | |||
* | The list of contexts in hierarchical order is as follows: | ||
* | *System context - accessible via the administrator's block (no parent) | ||
* | *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 | 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== | ||
Capabilities are aggregated and controlled via roles. Stated another way, a role consists of a list of capabilities for different possible actions within Moodle ( | 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== | ==Upgrading to 1.7== | ||
The upgrade to 1.7 is as smooth as we could make it. The existing roles (admin, teacher, student | 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== | ==See also== | ||
*[[Development:Roles]] | *[[Development:Roles]] | ||
*[[:Category:Capability]] | |||
*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] | ||
Revision as of 11:57, 29 November 2006
Roles
Previous Moodle versions had predefined, fixed roles. There was no easy way to change what a teacher, or student, for instance, could do. While fixed roles are adequate for many users, others require greater flexibility in regulating how users see and interact with the system.
With Roles, authorised users may create any number of customised roles and assign them to users. From 1.7, an organisation may create multiple roles so that, for instance, students assigned Role A could post to forums, while students assigned Role B are prevented from posting.
Definitions
- A role is an identifier of the user's status in some context, for example teacher, student and forum moderator.
- A capability is a description of a particular Moodle feature, for example moodle/blog:create. Capabilities are associated with roles.
- A permission is a value that is assigned for a capability for a particular role, for example allow or prevent.
- 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.
Contexts
The list of contexts in hierarchical order is as follows:
- System context - accessible via the administrator's block (no parent)
- 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.
