Roles and Permissions in Moodle Administration-part2

Moodle Administration

September 2008


An administrator's guide to configuring, securing, customizing, and extending Moodle

Capabilities and Permissions

So far, we have given users existing roles in different Moodle contexts. In the following few pages, we want to have a look at the inside of a role that is called capabilities and permissions. Once we have understood them, we will be able to modify existing roles and create entirely new custom ones.

Role Definitions

Existing roles are accessed via Users | Permissions | Define Roles in the Site Administration block. The screen that will be shown is similar to the familiar roles assignment screen, but has a very different purpose:

Roles and Permissions in Moodle Administration-part2

When you click on a role name, its composition is shown. Each role contains a unique Name, a unique Short name (used when uploading users), and an optional Description.

Roles and Permissions in Moodle Administration-part2

The Legacy role type has been introduced for backward compatibility, to allow old legacy code that has not been fully ported to work with the new system comprising new roles and capabilities. It is expected that this facility will disappear in the future (this might be for some time since a lot of core code depends on it), and should be ignored in due course unless you are working with legacy code or third-party add-ons.

In addition to these four fields, each role consists of a large number of capabilities. Currently, Moodle's roles system contains approximately 200 capabilities. A capability is a description of a particular Moodle feature (for example) to grade assignments or to edit a Wiki page. Each capability represents a permissible Moodle action:

Roles and Permissions in Moodle Administration-part2

Permission is a capability and its value, taken together. So each row of the table in the screen shot represents permission. The left column is the capability name and the radio buttons specify the value. So now permission has a description, a unique name, a value, and up to four associated risks.

The description, for example, Approve course creation provides a short explanation of the capability. On clicking, the description or the online Moodle documentation is opened in a separate browser. The name, for instance moodle /site: approvecourse, follows a strict naming convention that identifies the capability in the overall role system: level/type: function. The level states to which part of Moodle the capability belongs (such as moodle, mod, block, gradereport, or enroll). The type is the class of the capability and the function identifies the actual functionality.

The permission of each capability has to have one of the four values:



Not Set

By default, all permissions for a new role are set to this value. The value in the context where it will be assigned will be inherited from the parent-context. To determine what this value is, Moodle searches upward through each context, until it 'finds' an explicit value (Allow, Prevent or Prohibit) for this capability, i.e. the search terminates when an explicit permission is found. For example, if a role is assigned to a user in a Course context, and a capability has a value of 'Not set,' then the actual permission will be whatever the user has at the category level, or, failing to find an explicit permission at the category level, at the site level. If no explicit permission is found, then the value in the current context becomes Prevent.


To grant permission for a capability choose Allow. It applies in the context in which the role will be assigned and all contexts which are below it (children, grand-children, etc). For example, when assigned in the course context, students will be able to start new discussions in all forums in that course, unless some forum contains an override or a new assignment with a Prevent or Prohibit value for this capability.


To remove permission for a capability choose Prevent. If it has been granted in a higher context (no matter at what level), it will be overridden. The value can be overridden again in a lower context.


This is the same as Prevent, but the value cannot be overridden again in a lower context. The value is rarely needed, but useful when an admin wants to prohibit a user from certain functionality throughout the entire site, in which case the capability is set to Prohibit and then assigned in the site context.


Principally, permissions at lower contexts override permissions at higher contexts. The exception is "Prohibit", which by definition cannot be overridden at lower levels.

Resolving Permission Conflicts

There is a possibility of conflict if two users are assigned the same role in the same context, where one role allows a capability and the other prevents it. In this case, Moodle will look upwards in higher contexts for a decider. This does not apply to Guest accounts, where "Prevent" will be used by default.

For example, a user has two roles in the Course context, one that allows functionality and one that prevents it. In this case, Moodle checks the Category and the System contexts respectively, looking for another defined permission. If none is found, then the permission is set to "Prevent".

Permission Risks

Additionally, 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:





Roles and Permissions in Moodle Administration-part2

Users can change site configuration and behavior.


Roles and Permissions in Moodle Administration-part2

Users can add files and texts that allow cross-site scripting (potentially malicious scripts which are embedded in web pages and executed on the user's computer).


Roles and Permissions in Moodle Administration-part2

Users can gain access to private information of other users.


Roles and Permissions in Moodle Administration-part2

Users can send spam to site users or others.

Risks are only displayed. It is not possible to change these settings, since they only act as warnings. When you click on a risk icon, the "Risks" documentation page is opened in a separate browser window.

Moodle's default roles have been designed with the following capability risks in mind:

<!--[if gte mso 9]> Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 <![endif]--><!--[if gte mso 9]-->

Overriding Roles

It is possible to override permissions of a role in a given context using the Override permissions tab in the roles assignment screen. 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 existing rights.

For example, if pupils with the role of Student in a course are usually allowed to start new discussions in forums, but there is one particular forum for which you want to restrict that capability. You can then set an override that prevents the capability of students to start new discussions in this forum (namely mod/ forum: startdiscussion).

Overrides can also be used to open up areas of your site and courses to grant users extra permissions. For example, you may want to experiment giving students the ability to grade some assignments (see the following screenshot) or to peer rate forum posts:

Roles and Permissions in Moodle Administration-part2

Depending on the context in which permissions are being overridden, only relevant capabilities are shown. For example, in the preceding example, only four capabilities are displayed. The underlying gray boxes show permissions that have been copied. The highlighted value is the value of this permission in this role in the parent context. In the screenshot, it would therefore make no difference whether the capability values View assignment and Submit assignment are set to Allow or left at Inherit.

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 the block from guests on the front page, access the roles page of the block (editing has to be turned on), go to the Override permissions tab, select the guest role, and set the capability moodle/block:view to prevent, and then save the changes made.

Creating Custom Roles

As mentioned, Moodle allows the creation of new roles. Examples of such custom roles are Parent, Teaching Assistant, Secretary, Inspector, and Librarian. New roles are defined at Users | Permissions | Define Roles in the Site Administration block using the Add a new role button:

Roles and Permissions in Moodle Administration-part2

Duplicating a role is a commonly-used way of creating a new role. It not only minimizes the amount of work required, but also reduces mistakes in new roles.

Example Roles

MoodleDocs has provided a number of sample roles that might be relevant to your organization. If not, they offer a good starting point to create other roles:

Parent or Mentor 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, guardees, 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 the user context.

  1. Create new role:
    1. Go to Users | Permissions | Define roles in the Site Administration block
    2. Add a new role and name it Parent or Mentor. Provide an appropriate short name and a description.
    3. Leave the Legacy role type set to None
    4. Change the capability moodle/user:viewdetails to Allow. This grants access to the user profile page.
    5. Change the following capabilities in the User section to Allow, which grants access to individual tabs 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
  2. Create user account for parent:
    Each parent requires a separate user account (Go to Users | Add a new user in the Site Administration and add details for the parent or use Moodle's bulk upload facility). In our example, the father is called Roy Harris and his children are called Frank Harris and Paul Harris:
  3. Roles and Permissions in Moodle Administration-part2


  4. Link parent to pupil:
    Each parent has to be linked to each child. Unlike the creation of users, this process cannot be automated via batch files and is a potentially time-consuming process
    1. Access the first child's profile page and click on the Roles tab (Frank Harris).
    2. Choose Parent as the role to assign
    3. Select the parent (Roy Harris) in the potential users list and add it to the existing users list.
    4. Repeat the steps (a) to (c) for the second child, Paul Harris
  5. Add mentee block:
    1. Go to your front page and turn on editing.
    2. Add the Mentees block to the front page (it can also be added as a sticky block in My Moodle) and change its title via the configuration icon to Parent Access.
    3. Log in as Roy Harris and you should see the following block:

      Roles and Permissions in Moodle Administration-part2

  6. A special Mentees block has been introduced to facilitate access to user information.

When selecting a name, the respective user profile will be shown, which includes any posts sent to forums, blog entries and activity reports, including logs and grades

Testing New Roles

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 login as newly created user to test the new role. Alternatively, use a different browser (not a new window in the same 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 in the Site Administration block, select a role, and press the Reset to defaults button. This will replace its existing values with the one from the built-in legacy capabilities.


In this article, you have learned what roles are and how they are applied in different contexts. We then covered the modification of existing roles before creating our own custom roles, such as Parent, Inspector, or Librarian.

Getting your head around the roles concept in Moodle is vital if you wish to add/ remove functionality for a distinct group of users. As always, there is a trade-off between the complexity of such a system and its flexibility. While you can argue about the user-friendliness of the roles system, it has certainly proven to be one of the most powerful additions to Moodle when it was introduced back in version 1.7.

The interconnection among courses, users, and roles is crucial. Once this has been set up and configured properly, your Moodle is technically ready to go.

For all those who have missed the first part of the article,
just click :

If you have read this article you may be interested to view: Front Page Customization in Moodle

Books to Consider

comments powered by Disqus

An Introduction to 3D Printing

Explore the future of manufacturing and design  - read our guide to 3d printing for free