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

Roles and capabilities

From MoodleDocs
Revision as of 13:19, 29 March 2007 by Helen Foster (talk | contribs) (simplifying, transferring content to other pages)


Moodle1.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