Contexts are the areas in Moodle where roles can be assigned to users. A role (remember, a collection of capabilities with corresponding permissions) can be assigned within different contexts. A user has a role in any given context; a context can be a course, a course category, an activity module, a user, a block, or Moodle itself. Moodle comes with seven contexts that you will come across a lot in this chapter:

Each context is like a ring-fenced area or boundary in which certain actions can be carried out. It is also sometimes referred to as a scope. You can compare this to a large company with multiple divisions and departments. A manager of the finance division has certain rights and responsibilities for every department in his division, but these do not apply to departments in other divisions of the organization.

To implement such a structure, it is important that role assignments to users should be made at the correct context level. For example, a teacher role should be assigned at the Course context level, a moderator for a particular forum should be assigned at the Activity context level, an administrator should be assigned at the System context level, and so on. While it is technically possible to assign any role in any context, some roles just don't make any sense. Unfortunately, Moodle doesn't warn you about this, since it cannot distinguish between intentional and unintentional assignments.

Contexts are hierarchical, that is, permissions are inherited from higher to lower contexts. Rights in a higher context are more general, whereas the ones at a lower context are more specific. The same applies in the company structure mentioned earlier—a sales manager at country level would have the same rights at regional level, whereas the opposite is not true.

The following diagram shows the contexts that exist in Moodle and how they are arranged hierarchically:

The System context is the root node of the hierarchy, that is, every role assigned in this context will apply to any other context below it. The Course Category context on the next level acts as a parent to the Course context. If Sub-Category and Sub-Sub-Category, and so on, have been created, respective contexts will exist. On the lowest level, you can see the Module and Block contexts, respectively. Like the Course context, the Front Page context has a Module and Block sub-context (the front page is internally treated as a course). The User context is a standalone entity that does not have any children in the hierarchy.

For example, Jim is a teacher for a course. He is assigned a Teacher role in the relevant context (that is, the class he is teaching). He will have this role in all the areas of the course, including blocks and activity modules (that is, activities and resources). If however, Jim had been assigned the Teacher role in the Course Category context instead, he would have the same rights in all the courses in this category and all its sub-categories. This also means that he will receive e-mails about all the assignments, in all the courses, even if he doesn't teach in them.

Organizing contexts hierarchically has a number of advantages that will sound familiar to readers who have knowledge of object-oriented technologies: