Every complex system offers various usage patterns based on user needs and obligations. Based on such use cases we can identify specific roles. Moodle is no different in this respect. For example, we know for sure that we must have a person dedicated to maintaining the platform, monitoring, and fixing any issues that may arise at a time—that person should have the role of a general manager or in Moodle terminology, an administrator. Another example would be a user that is a course participant. His principal interest is to browse through all available learning materials and participate in any tasks set for him—this would be learner or student. Each and every role has a set of things that are permitted or prohibited. By assigning users to one of the predefined or custom roles we are defining the spectrum of the options and actions available to them at every location within LMS. It is paramount for every administrator to fully understand access rights as they are implemented. Therefore, in this chapter we will focus on access rights to resources and functions within Moodle starting with:
- Roles and capabilities
- Standard roles
- Customizing roles
- Best security practices with roles
The Moodle access rights system is based around the concepts of contexts, capabilities, permissions, and roles. Let us first define these terms in the context of Moodle.
A capability is a system defined feature or action. For example, view course would be one capability. All capabilities are defined either by Moodle core or by third-party module(s).
Context is an abstraction representing part of Moodle. We have six predefined contexts and they are arranged in a hierarchical fashion with permissions inherited from higher to lower contexts. Here is the list of existing contexts presented in order of importance from higher to lower:
- System: This context represents the entire Moodle. Any role assigned at this level applies globally on the entire system. For example, if we assign the teacher role to a user he will have that role in every course and would be able to manage them as if enrolled in every one of them.
- User: This context for a specific user. It context can be used to assign partial or complete management rights on the user related and generated content outside of the course (profile, blog, messages, etc.). Usually, it is used for giving partial or full access of subject's data to HR staff or relatives/parents.
- Course category: The courses always belong to some category, so this context applies to anything within that category or subcategory.
- Course: Context for a specific course.
- Activity: This context describes particular activity within a course.
- Block: This context applies to a particular type of block.
Permission defines whether capability is enabled or not. Each capability can be given permission on a particular context. There are four permissions defined:
- Not set: If a capability has this setting in a particular context it behaves exactly same as the Prevent permission by default following a rule "prohibit everything that is not explicitly allowed". However, if there is another role in the lower context with a different value then it will override this setting.
- Allow: Enables capability.
- Prevent: Disables capability in a context for a specific user.
- Prohibit: This is effectively the same as Prevent but it also prohibits overriding that same capability in lower level contexts.
A Role answers to a question: what can the user do? and is also a predefined list of permissions applied to all capabilities within the system. With Role we can easily separate what one group of users can and cannot do in the specific part of the platform. It is important to say that any user can and usually will have more than one role applied on the same context. Moodle poses no limits in that area, but we still should be conservative in the way we assign and use roles.
Whenever a user wants to perform a specific action in some context, Moodle checks his permission level for it. This is done by reviewing all permissions from all roles that are assigned to that user at that particular context. The result of that review produces computed permission as a sum of enabled, disabled, or not set values taking into account context precedence.
For example, a user logs into Moodle and wishes to enter into a course. Upon logon, every user is assigned the Authenticated user role (this is the default and recommended setting for most use cases but it can be modified). Whether a user can see a course or not is determined by a state of course_view capability for that user within a role he has in that course context. Moodle gets all roles for that user starting from the system level down to the course level. It can be presented with the following table:
|
User |
Context |
Role |
Capability |
Permission |
|---|---|---|---|---|
|
Student1 |
System |
Authenticated user |
course_view |
not set |
|
User | ||||
|
Course category | ||||
|
Course 1 |
Student |
course_view |
allowed |
As you can see a user has no role whatsoever for some contexts which is normal in Moodle. We are showing them just for the sake of completeness.
In this simple case we have two instances of the course_view capability. One is not set while the other is set to allowed. The basic formula for calculating resulting permission can be described like this:
Start from the context of the resource we want to access, get user role(s) (if any) for it, and get permission value(s) for specific capability. If a user has more than one role defined in that context, permission values are summed in the resulting value. If any of the permissions has the value "prohibit" it finishes the check and denies access to the user, otherwise save current computed permission value and go to the parent context. If there is a parent context, repeat the process. Otherwise, return the computed permission. If the final permission value is bigger than or equal to 1, then the user is granted access.