[ Send this article ]
Your message has been sent.
How would you like to send this article:
[ Save this article ]
Save this article to your account for easy access.
This article has been saved to your account.
Go to my account
This article has been emailed to your Kindle.
Send this article
Complete the form below to send this article, Roles and Permissions in Moodle Administration-part2, to a friend (or to yourself). We will never share your details (or your friend's) with anyone. For more information, read our Privacy Policy.
by
Alex Büchner | April 2009 |
Moodle
This article is the second part of a two-part series. In the first part of this series, you learnt:
- Understand how roles work, and how they fit into different contexts.
- Assign roles to different users in different contexts.
In this article, you will:
- Modify roles and create new ones, including a role for parents or mentors.
- Manage a range of administrative role-related settings.
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:
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.
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:
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:
|
Permission |
Description |
|
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. |
|
Allow |
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. |
|
Prevent |
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. |
|
Prohibit |
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:
|
Risk |
Icon |
Description |
|
Configuration |
|
Users can change site configuration and behavior. |
|
XSS |
|
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). |
|
Privacy |
|
Users can gain access to private information of other users. |
|
Spam |
|
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]>
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:
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:
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:
- Inspector (http://docs.moodle.org/en/Inspector_role):
The role is used to provide external inspectors or verifiers the permission to view all courses in Moodle without having to enroll. - Demo teacher (http://docs.moodle.org/en/Demo_teacher_role):
The role is used to provide a demonstration teacher with an account that has a password and profile that cannot be changed. - Forum moderator (http://docs.moodle.org/en/Forum_moderator_role):
The 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. - Calendar editor (http://docs.moodle.org/en/Calendar_editor_role):
The role is used to enable a person to add site events to the calendar - Question creator (http://docs.moodle.org/en/ Question_creator_role):
The role is used to enable students to create questions for use in quizzes - Blogger (http://docs.moodle.org/en/ Blogger_role):
The role is used to limit blogging to specific users.
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.
- Create new role:
- Go to Users | Permissions | Define roles in the Site Administration block
- Add a new role and name it Parent or Mentor. Provide an appropriate short name and a description.
- Leave the Legacy role type set to None
- Change the capability moodle/user:viewdetails to Allow. This grants access to the user profile page.
- 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
- 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: - 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- Access the first child's profile page and click on the Roles tab (Frank Harris).
- Choose Parent as the role to assign
- Select the parent (Roy Harris) in the potential users list and add it to the existing users list.
- Repeat the steps (a) to (c) for the second child, Paul Harris
- Add mentee block:
- Go to your front page and turn on editing.
- 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.
- Log in as Roy Harris and you should see the following block:
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.
Summary
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 : http://www.packtpub.com/article/roles-and-permission-moodle-administration-part1
If you have read this article you may be interested to view: Front Page Customization in Moodle
About the Author :
Alex Büchner
Alex Büchner is the co-founder and technical lead of the leading Moodle, Totara and Mahara partner, Synergy Learning. He has been involved in system and database administration for more than two decades and has been administering virtual learning environments of all shapes and sizes since their advent on the educational landscape.
Alex holds a PhD in Computer Science and an MSc in Software Engineering. He has authored over 50 international publications, including two books, and is a frequent speaker on Moodle, Totara and Mahara, and related open-source technologies. His first book on Moodle Administration by Packt Publishing has become the de facto standard on the topic.
Post new comment