Roles and permissions: Difference between revisions
Helen Foster (talk | contribs) (simplifying, transferring content to other pages) |
|||
Line 1: | Line 1: | ||
{{Roles}} | {{Roles}} | ||
{{Moodle 1.7}} | {{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== | ==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 ''[[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. | ||
==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] | ||
[[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.