So far, we have given users the existing roles in different Moodle contexts. In the following few pages, we want to have a look inside a role where capabilities dictate what functionality is allowed. Remember, a role is a collection of capabilities with corresponding permissions. Once we have understood capabilities, we will modify the existing roles and create entirely new, custom ones.
The existing roles are accessed via Users | Permissions | Define roles. The screen that will be shown is similar to the familiar Assign roles screen, but has a very different purpose:
When you click on a role name, its composition is shown. Each role contains unique Short name (used when uploading users), Custom full name, and optional Custom description:
The Role archetype field specifies which permissions are set if the role is reset to its default value. The setting further determines what values any new permissions will have, when introduced in future versions of Moodle. These settings will then be applied during the update process.
The Context types where this role may be assigned field is set to the context in which the role will be allowed as an option. This reduces the risk that roles are assigned in contexts where they shouldn't. We have already come across this when we tried to assign roles in the Block or User context, and Moodle prevented us from doing so.
The next three fields (Allow role assignments, Allow role overrides, and Allow role switches) show which roles users who are assigned the current role are allowed to assign, override, and switch, respectively. The Role risks field indicates which of the four available risks the current role has. All this information will make more sense once we have dealt with it in more detail.
In addition to these parameters, each role consists of a large number of capabilities. Currently, Moodle's role system has more than 400 of them. If you have installed plugins, this number might even be higher.
Examples are grading an assignment or editing a Wiki page. Each capability represents a permissible Moodle action and is displayed as a single row in the list of all the capabilities.
To simplify searching for capabilities, use the provided Filter mechanism. It only shows the capabilities (with both—the name as well as the description) that match the filter criterion:
Each capability has the following components:
- Description: The description, for example, Upload new users from file, provides a short explanation of the capability. On clicking a capability, the online Moodle documentation for that capability is opened in a separate browser window.
- Name: The name, for instance moodle/site:upload users, follows a strict naming convention—
level/type:function—which identifies the capability in the overall role system. The level states to which part of Moodle the capability belongs (such asmoodle,mod,block,gradereport, orenrol). The type is the class of the capability, and the function identifies the actual action. - Permission: The permission of each capability has to have one of the four values, explained in the following table:
- Risks: Moodle displays the risks associated with each capability, that is, the risks that each capability can potentially raise. They can be any combination of the following four risk types:
Moodle's default roles have been designed with the following capability risks in mind:
|
Role |
Allowed risks |
|---|---|
|
Administrator |
All capabilities, with a few exceptions |
|
Teacher |
Certain capabilities with XSS and privacy risks, mainly adding and updating content |
|
Student |
Certain capabilities with spam risks |
|
Guest |
Only capabilities with no risks |
To edit a role, either click on the Edit button at the top of the View role details screen or select the appropriate icon in the Edit column on the main roles screen.
When editing a role, you can change the standard fields as well as its permissions. For example, some schools change the role name student to pupil, while some training organizations change the role name teacher to instructor. Bear in mind that this only changes the name of the role, not the corresponding labels used throughout Moodle. You will learn how to do this in the Localization section in Chapter 9, Moodle Configuration.
When you change capabilities in a role that has been derived from a Role archetype, its original values are highlighted when you click on the Show advanced button. For example, in the following screenshot, Manage templates has been set to Not set, but the Allow value remains highlighted; do not forget to save your role changes, once applied:
Unless you are confident with role modifications, it is recommended to duplicate a role first (via the Export functionality on the top of this screen and the creation of a new role described further down) and then edit it. Keeping the default roles untouched also makes maintenance easier in case multiple administrators work on the same system or a third party is providing support.
For example, if, due to privacy or other reasons, your organization decides not to allow users to see the profiles of other users, you would edit the Student role, search for the moodle/user:viewdetails capability, and change it from Allow to Not set.
It is possible to override permissions of a role in a given context using the Permissions link in the role assignment screen. You are shown a screen that describes which role has been given or has inherited permission for any of the capabilities of the current module activity (here, an assignment):
Overrides are specific permissions designed to change a role in a specific context, allowing you to tweak your permissions as required. Tweaking involves granting additional rights or revoking the existing rights. Once you select a role from the Advanced role override drop-down menu, you will see a familiar screen that shows the details of each capability of the activity for this particular role.
For example, while learners with the role of student in a course are usually allowed to start new discussions in forums, there is one particular forum for which you want to restrict that capability; you can set an override that prevents the capability for students to start new threads in this forum (namely, mod/forum:startdiscussion).
Overrides can also be used to open up areas of your site and courses to grant extra permissions to the users. For instance, you may want to experiment giving students the ability to grade some assignments (see the following screenshot) or to peer rate forum posts.
Moodle allows the creation of new roles. The examples of such custom roles are parent, teaching assistant, secretary, inspector, and librarian in an educational setting and training coordinator, assessor, mentor, or staff manager in a business context. The new roles are defined at Users | Permissions | Define roles using the Add a new role button.
Before you get to the familiar role-editing screen, you have the option to select an existing role or archetype from the drop-down menu, or to import a role (in XML format) that has been exported either in your Moodle instance or in another system (using the Export button when viewing role details).
Using the existing roles as a basis is a commonly-used way of creating a new role. It not only minimizes the amount of work required, but also reduces errors in creating new roles. If you wish to create a role from scratch, that is, without any presets or inherited archetypes, leave both settings empty and continue to the next screen.
Make sure that you specify Context types where this role may be assigned. If you miss out a context, it will not be possible to assign the role. If you allow a context that is not suitable for the role, you run the risk that it will potentially cause problems.
Moodle Docs has provided a number of sample roles that might be relevant to your organization (for example, refer to the custom roles section at https://docs.moodle.org/en/Creating_custom_roles). If not, they offer a good starting point to create other roles. Some useful samples are as follows:
- Demo teacher: This role is used to provide a demonstration teacher an account that has a password and profile that cannot be changed (for more details on this role, visit https://docs.moodle.org/en/Demo_teacher_role)
- Forum moderator: This role is used in a particular forum and provides a user with the ability to edit or delete forum posts, split discussions, and move discussions to other forums (for more details on this role, refer to https://docs.moodle.org/en/Forum_moderator_role)
- Calendar editor: This role is used to enable a user to add site events to the calendar (for more details on this role, refer to https://docs.moodle.org/en/Calendar_editor_role)
- Question creator: This role is used to enable students to create questions for use in quizzes (for more details on this role, refer to https://docs.moodle.org/en/Question_creator_role)
- Blogger: This role is used to limit blogging to specific users (for more details on this role, refer to https://docs.moodle.org/en/Blogger_role)
One of the most popular and sought-after custom roles in Moodle is the one of a parent, guardian, or mentor. The idea is to grant permission to users to view certain profile information, such as activity reports, grades, blog entries, and forum posts of their children, wards, or mentees. This can be achieved with the creation of a new role. Furthermore, the specially-introduced Mentees block has to be placed on the front page to give users, who have been assigned the role, access to the User context.
For creating a new role, follow these steps:
- Go to Users | Permissions | Define roles.
- Add a new role, continue on the Defaults screen, and name it Parent or Mentor. Provide an appropriate Shortname and Description.
- Leave the Role archetype type set to None.
- Check the User checkbox for the Context types where this role may be assigned field.
- Change the capabilities moodle/user:viewdetails and moodle/user:viewalldetails to Allow. This grants access to the user profile page.
- Change the following capabilities in the Users section to Allow, which grants access to individual areas on the user profile page:
- moodle/user:readuserposts: To read the child's forum posts
- moodle/user:readuserblogs: To read the child's blog entries
- moodle/user:viewuseractivitiesreport: To view the child's activity reports and grades
- Save the role using the Create this role button.
- Create a user account for parent. Each parent requires a separate user account, which is set up as explained in the previous chapter (go to Users | Accounts | Add a new user and add details for the parent or use Moodle's bulk upload facility). In our example, the father is Roy Harris and his children are Frank Harris and Paul Harris, as shown in the following screenshot:
- Link parent to pupil. Each parent has to be linked to each respective child. Unlike the creation of users, this process cannot be automated via batch files yet and is a potentially time-consuming process. It is expected that this feature will be added to user batch creation in the near future. There exists a contributed plugin (https://tracker.moodle.org/browse/CONTRIB-3938), which supports automatic role assignment of several parents/mentors from LDAP or a database.
- Access the first child's profile page, select the Preferences link in the Administration pane and click on Assign roles relative to this user.
- Choose Parent as the role to assign.
- Select the parent (Roy Harris) from the Potential users list and add him to the Existing users list.
- Repeat the first three steps for the second child, Paul Harris.
- A special Mentees block has been introduced to facilitate access to user information. Follow these steps to add it:
- Go to your front page and click on the Turn editing on link.
- Add the Mentees block to the front page (it can also be added on the default dashboard) and change its title to Parent access via the Configuration icon.
- Login as Roy Harris, and you should see the following block:
When a name is clicked upon, the respective user profile will be shown, which includes any posts sent to forums, blog entries, and activity reports, including logs and grades.
After creating a new role, it is recommended to test it thoroughly before it is assigned to any users. To do this, create a test account and assign the new role to it. Log out as administrator and log in as the newly-created user to test the new role or use the Login as function to masquerade as the test user. Alternatively, use a different browser to test out the role without logging out as administrator.
If you have modified a predefined role and would like to roll back to its factory settings, go to Users | Permissions | Define roles, select (do not edit) a role, and click on the Reset button. This will replace its existing values with the one from the built-in capabilities.
The complexity of the roles system and the ability to assign multiple roles to multiple users in multiple contexts calls for a mechanism to verify the correctness of the permissions set. This problem is amplified by the fact that permissions can be inherited and then overridden at lower levels again.
Moodle has a built-in permission checker that displays the values of any capabilities in the context in which the checker has been called. The facility is called via the Check permissions link in a specific context. For example, in the following screenshot, we have called the permission checker in the User context of Paul Harris and showed the permissions of user Roy Harris. It confirms the settings of the earlier created Parent role.
At site level, there are two additional mechanisms that help to identify any potential issues with roles. The capability report (Users | Permissions | Capability overview) shows, for a selected capability, what permission it has in the definition of one or many selected roles. It also shows if the capability has been overridden anywhere in the system, which is a great help when you try to locate any local modifications.
In the example screenshot, I have selected the capability mod/forum:rate: Rateposts and All roles. The report that follows shows the values of the capability in all the roles. Of particular interest is the Student role, which is shown all the way down to the forum in a course, where it has been overridden:
The second tool can be found at Users | Permissions | Unsupported role assignments. As the name suggests, it lists any role assignments that are not valid. This usually happens when you upgrade from a previous version of Moodle. If any assignments are listed, you will have to manually modify or remove them.