[ 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: Part1, 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
In this article by Alex Büchner, we will introduce roles—a complex but powerful subject. Roles define what users can or cannot see and perform in your Moodle system. The article later explains assignment of roles, modifying them, over riding them, creating custom roles with example and finally testing those new roles to perform a reality check. We also explain how to resolve permission conflict in Moodle's Roles.
In the first part you will:
- Understand how roles work, and how they fit into different contexts.
- Assign roles to different users in different contexts.
In the next part you will:
- Modify roles and create new ones, including a role for parents or mentors.
- Manage a range of administrative role-related settings.
Lets get started.
Moodle's PreDefined Roles
Moodle comes with a number of predefined roles. These standard roles are suitable for some educational setups, but most institutions require modifications to the roles' system in order to tailor Moodle to their specific needs.
Each role has permissions for a number of actions that can be carried out in Moodle. For example, an administrator and a course creator are able to create new courses, whereas all other roles are denied this right. Likewise, a teacher is allowed to moderate forums, whereas students are only allowed to contribute to them.
The description of each standard role and the short names (that are used internally and in operations such as user batch upload) given by Moodle are listed in the table that follows:
|
Role |
Description |
Short Name |
|
Administrator |
Administrators have full access to the entire site and to all courses. |
admin |
|
Course Creator |
Course creators can create new courses and also teach in them. |
coursecreator |
|
Teacher |
Teachers can do anything within a course, including changing activities and grading students. |
editingteacher |
|
Non-editing Teacher |
Non-editing teachers can teach in courses and grade students, but not alter any activities. |
teacher |
|
Student |
Students are able to perform allocated tasks which include resources and activities, among others. |
student |
|
Guest |
Guests have minimal privileges and usually cannot enter text anywhere. |
guest |
|
Authenticated User |
Additional role given once logged in. It is an exception role and is mostly used by Moodle internally. |
user |
Before we can actually do anything with roles, we need to understand the concept of contexts, which is dealt with next.
Contexts
Contexts are the areas in Moodle where roles can be assigned to users. A role can be assigned within different contexts. A user has a role in any given context, where a context can be a course, an activity module, a user, a block, or Moodle itself. Moodle comes with the following seven contexts that you will come across a lot in this article.
<!--[if gte mso 9]>
System Context
The System context covers the entire Moodle system. Assignment takes place from the Site Administration block in Users | Permissions | Assign system roles:
You see the familiar screen, which allows the assignment of roles to users. The only difference to the outlined generic screen is the absence of the Roles tab at the top of the screen that does not apply on the top-level context. Instead, a warning is displayed, as seen in the screenshot.
In most Moodle systems with predefined roles, only the Administrator role should be granted at this level. For example, if a Teacher role is granted in the Site context, it means that the individual would not only be allowed to access every single course in the site, but would also have the rights to mark assignments, contribute to discussion forums, delete learning resources, and so on.
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 global level.
Course Category Context
The Course category context covers all courses within a category and all of its sub-categories. The role assignment takes place in the Site Administration block in Courses | Add/edit course, where you have to select the category you wish to deal with (If editing has been turned off, it has to be turned on first.):
The Assign roles link at the top right will direct you to the familiar roles assignment screen. In the screenshot, the selected category is called Miscellaneous. The same mechanism applies to sub-categories and sub-sub-categories, and so on.
A typical role that is assigned in the Category context is Course creator. It will allow a dedicated user to create new courses within the specified category, which is very often a department or division. In smaller organizations, it is possible to assign the Teacher role access to all courses within the category.
Course Context
As the name suggests, in this context all assignments that cover a course are granted. The assignment takes place in the actual course. You must select the Assign roles link in the menu in the Site Administration block. This will direct you to the familiar Assign roles screen.
Alternatively, you can get to the same screen by selecting Courses | Add/edit course in the Site Administration block, where you have to select the category in which your course is located. (If editing has been turned off, it has to be turned on first.) Beside each course, you will find the Assign roles icon that has to be selected:
The course context is most frequently used for assigning roles since, in most cases, a course has a teacher and a number of students where everybody has the same rights. The example used to explain the assignment of roles earlier is from a Course context.
When a student is enrolled to a course, either by self-enrollment or any other enrollment mechanism, Moodle will automatically assign that student a role in the relevant course (context). This also applies if you upload users in batch mode and provide a course a user has to be enrolled to.
Module Context
The Module context is often used by teachers to assign new capabilities 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 she or he learns how to moderate discussions, she or he requires the rights to edit and delete posts (among others). These rights are provided by the Teacher role, and it is perfectly feasible to make a student a teacher in a single activity. It is further possible, and often recommended, to time the assignment via the enrollment duration option.
The Course context is the parent of the Module context. From Moodle 1.8 onwards, the Module context can also be a child of the Site context, which applies if an activity or resource is placed on the front page.
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.
Block Context
Similar to the Module context, the Block context allows the assignment of rights on block level within a course. You will see a roles icon in the top left corner of each block, which will lead to the Assign roles screen (Editing has to be turned on.):
Like the Module context, the Course context is the parent of the Block context. From Moodle 1.8 onwards, the Block context can also be a child of the Site context, which applies to any blocks that are placed on the front page.
Sticky blocks, whether in My Moodle or in the Course pages, are an exception to the rule and roles cannot be assigned in them. The roles icon is not displayed as it is in other blocks.
User Context
The User context is a standalone context, which has only the System context as parent. It deals with all issues relating 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 Roles tab in the user profile page, as seen in the following screen shot:
Roles assigned in the User context will only have access to information accessible from this user screen. Examples of custom roles are the Parent or Mentor role (which we will deal with in the example section of this article) and a Human Resources role.
Front Page Context
The Front Page context has the System context as parent, and like the Course context, Module and Block sub contexts. It is accessed via Front Page | Front Page roles in the Site Administration block:
The naming of the context is sometimes a little confusing. Front page files are generally accessed only via the front page. However, sometimes (for example) when storing a school policy file, files stored in the Front Page area are also accessed elsewhere in Moodle. This is the reason why the Site file sub-menu is positioned in the Front Page menu in the Site Administration block, as shown in the screen shot that follows.
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 sub-menus are accessible:
You can either assign the designer (user) an Administrator or a Teacher role. The administrator has the ability to assign other administrators, whereas the teacher does not have this permission. Either way, assigning a standard role in the context allows read-only access to user profiles and courses. If this is not acceptable, a separate Designer role has to be created.
Multiple Roles
It is not uncommon for a user to be assigned more than a single role. For example, a class teacher who is also made course creator is responsible for the Moodle administration, or acts as a support teacher in a different class. In fact, every logged in user is assigned the "Authenticated user" role in the System context.
In addition to the user's main role, the user can also fulfill one or more additional roles in other contexts. 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 put in charge of the sales division.
To specify an additional role, the actual context has to be selected as shown in the previous sub-sections. You will then be able to assign additional roles as necessary.
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, especially when you only use predefined roles. The real problem is the potential of conflicts, which Moodle has to resolve. For example, if one role has the ability to delete a forum post and another does not, but a user has been assigned both the 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.
Continue reading >> Roles and Permissions in Moodle Administration-part2
If you have read this article you may be interested to view :
- Integrating Moodle 2.0 with Alfresco to Manage Content for Business [Article]
- Integrating Moodle 2.0 with Mahara and GoogleDocs for Business [Article]
- Front Page Customization in Moodle
- Roles and Permissions in Moodle Administration-part2
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