The System context covers the entire Moodle system. Assignment takes place from Users | Permissions | Assign system roles. In our system, only two roles appear that can be assigned. We already mentioned that it doesn't make sense to assign certain roles in certain contexts. Inside a role, it is possible to specify in which context types may be assigned. Only these two roles have been selected, which is the reason for the limited choice.

You will see the familiar screen that allows the assignment of roles to users. The only difference from the generic screen outlined earlier is the WARNING! Any roles you assign from this page will apply to the assigned users throughout the entire system, including the front page and all the courses. warning.

In most Moodle systems with predefined roles, it only makes sense to assign the Manager role if you wish to allow read-only access to a user for all the courses, for example, an inspector, business manager, or school principal. Assigning the Course creator role to a user allows him/her to create new courses in any category. If, for example, a Teacher role is assigned in the System context, it means that the user would not only be allowed access to every single existing course in the site, but also to all the courses created in the future.

There are scenarios when global roles are justified, for instance, in very small organizations, or if Moodle hosts only a very small number of courses that are attended by all users. Also, some new user-defined roles, such as a school inspector, are designed to be assigned at a global level.

One role that can only be assigned at a system level is the Administrator role. This task has been given a dedicated area under Users | Permissions | Site administrators. When you installed Moodle, a primary administrator was created, which cannot be modified or deleted. You can, however, create additional administrator accounts. The procedure is identical to assigning users in any other context, with the exception that you have to confirm the assignment.

The Course Category context covers all the courses within a category and all of its sub-categories. The role assignment takes place under Courses | Manage courses and categories, where you have to select Assign roles in the respective course drop-down menu. The same mechanism applies to sub-categories, sub-sub-categories, and so on.

A typical role that is assigned in the Course Category context is the Course creator role. It will allow a dedicated user to create new courses within the specified category, which is very often a department or division. The standard Course creator role does not include teacher capabilities, that is, a course creator cannot edit course content. In smaller organizations, it may be required to grant the Teacher role access to all the courses within the category.

As the name suggests, in this context, all role assignments that cover a course are granted. The assignment takes place in the actual course. We have already come across this in Chapter 4, Course Management, when we dealt with enrolments. In fact, enrolments in courses are treated as roles in the Course context. As enrolments contain some unique options (start date, end date, and a suspension option) and due to the fact that these enrolments are often carried out by (non-technical) teaching staff, a different user interface has been implemented. However, within a course, when you go to Users | Enrolment methods in the Settings block and then click on the Enrol users icon in the Edit column of the Manual enrolments method, you will see a familiar-looking screen. We have already dealt with the additional expiry options in the center of the screen when we covered enrolments.

When a student is enrolled in a course, either by self-enrolment or any other enrolment mechanism, Moodle will automatically assign the Student role in the relevant Course context. This also applies if you upload users in batch mode and specify a course to which a user has to be enrolled.

If you have to assign roles to users who are not enrolled, but have a role in the course, go to Users | Other users in the Settings block and click on the Assign roles button. This applies to the Manager role, for instance, or a newly-created role, such as supervisor teacher. The user interface is in line with the enrolment interface, not the general roles interface:

The preceding screenshot also displays any users who have inherited a role in this course, for instance, one user has been assigned in the Course category context and one at the System level (see arrows in the preceding screenshot).

Once you are inside a course, it is possible to assign roles to users for individual modules, such as resources and activities. While editing the module properties, you will see three role-related links in the activity-specific Administration block. The one labeled Locally assigned roles will lead to the familiar screen to Assign roles. The Permissions and Check permissions links let you change the inherited roles and verify the roles of the individual users. We will deal with this later in the chapter.

The Module context is often used by teachers to grant additional rights to their students. A regularly-cited example is that of a forum moderator. If you wish to put a student in charge of a forum so that he/she learns how to moderate discussions, he/she requires the rights to edit and delete posts (among others). These rights are provided by the Teacher role and it is perfectly feasible to assign a Teacher role to a student in a single activity.

By default, users with a Teacher role have the rights to assign roles in the Module context. However, it is often up to the Moodle administrator to carry out the task on their behalf due to the complexity of the roles system. The same applies to the Block context, which is covered next.

Similar to the Module context, the Block context allows the assignment of rights on block level within a course. You will see an Assign roles link in the drop-down menu when selecting the Actions icon (editing has to be turned on).

If your system doesn't contain a role that has been granted rights to be assigned in the Block context, you will see a menu item, Permissions, instead. This is the case, by default. We will deal with modifying roles later on.

It is possible to control the users who can view blocks. For example, you might have a block that you don't want guest users to see. To hide that block from guests on the front page, access the roles page of the block by clicking on the Assign roles icon and then the Permissions link in the Administration block (or use the direct Permissions link if applicable). Select the Guest role from the Advanced role override drop-down list, set the moodle/block:view capability to Prevent, and click on Save changes. We will deal with capabilities further down.

The same mechanism also applies to blocks outside courses, whether on the front page, in My Moodle, on the default profile page, or inside activities.

The User context is a standalone context, which has only the System context as parent. It deals with all the issues relating to a user outside a course. They include the user's profile, forum posts, blog entries, notes and reports, logs, and grades.

The assignment of roles takes place in the profile of the user where you need to select Preferences in the Administration pane. The Assign roles relative to this user link does not appear, by default! You need to have a role that can be assigned in the User context. None of the predefined roles make sense to be applied in such a way, which is why this only applies to user-defined roles. An often-cited example of a custom role to be applied in the User context is the Parent/Mentor role, which we will deal with in the Creating custom roles section.

Roles assigned in the User context will only have access to information accessible from the user screen. They will not have access to any courses.

In Moodle, the front page is a course and, at the same time, not like a course. In other words, it is a special course! The Front page context has the System context as parent and, like the Course context, Module and Block as the sub-contexts. It is accessed via Front page settings | Users | Permissions | Assigned roles. We already looked at the familiar interface at the beginning of the section when explaining how to assign roles in general.

A typical user in the Front page context is a designer who is responsible for the layout and content of the front page of the Moodle system. When assigned, only the Front page menu and its submenus are accessible. Most sites apply either the Teacher role or create a dedicated designer role.

It is common for a user to be assigned to more than a single role. For example, a class teacher is also made course creator for the year group he is responsible for (Category context), or he is in charge of the Moodle administration (Site), or he acts as a support teacher in a different class (Course), or he is the parent of a child (User). In fact, every logged-in user is automatically assigned the Authenticated user role in the System context. We will deal with this later in the chapter.

A significant part of the roles infrastructure in Moodle is the ability to assign multiple roles to a user at the same time. The equivalent in our initial company example is a member of staff who is in charge of the marketing department, but is also temporarily assisting in the sales division where he/she is acting as a trainer.

To specify an additional role, the actual context has to be selected, as discussed earlier. You will then be able to assign additional roles as necessary.

The problem is the potential for conflicts, which Moodle has to resolve. For example, if one role has the ability to delete a forum post and another one does not, but a user has been assigned both roles in the same context, which right applies? While Moodle has a built-in resolution mechanism for these scenarios, it is best to completely avoid such scenarios.

In fact, it is technically possible to assign two or more roles to the same user in the same context. Having said this, it is hard to think of situations where such a setup would actually make sense.