Roles and Permissions in Moodle Administration: Part1

Exclusive offer: get 50% off this eBook here
Moodle Administration

Moodle Administration — Save 50%

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

£18.99    £9.50
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]> Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 <![endif]--><!--[if gte mso 9]-->
Moodle Administration An administrator's guide to configuring, securing, customizing, and extending Moodle
Published: September 2008
eBook Price: £18.99
Book Price: £30.99
See more
Select your format and quantity:

System Context

The System context covers the entire Moodle system. Assignment takes place from the Site Administration block in Users | Permissions | Assign system roles:

Roles and Permissions in Moodle Administration-part1

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.):

Roles and Permissions in Moodle Administration-part1

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:

Roles and Permissions in Moodle Administration-part1

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

Roles and Permissions in Moodle Administration-part1

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.):

Roles and Permissions in Moodle Administration-part1

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 and Permissions in Moodle Administration-part1

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:

Roles and Permissions in Moodle Administration-part1

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:

Roles and Permissions in Moodle Administration-part1

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 :

Moodle Administration An administrator's guide to configuring, securing, customizing, and extending Moodle
Published: September 2008
eBook Price: £18.99
Book Price: £30.99
See more
Select your format and quantity:

About the Author :


Alex Büchner

Alex Büchner is a co-founder and technical lead of the leading Moodle, Mahara, and Platinum Totara 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 has a PhD in Computer Science and an MSc in Software Engineering. He has authored over 50 international publications, including three books, and is a frequent speaker on Moodle, Totara and Mahara, and related open source technologies. His first two books on Moodle, published by Packt, have become the de facto standard on the topic.

Books From Packt

Drools JBoss Rules 5.0 Developer's Guide
Drools JBoss Rules 5.0 Developer's Guide

Plone 3 Theming
Plone 3 Theming

Moodle 1.9 Multimedia
Moodle 1.9 Multimedia

Apache Struts 2 Web Application Development
Apache Struts 2 Web Application Development

Drupal 5 Views Recipes
Drupal 5 Views Recipes

JBoss Tools 3 Developers Guide
    JBoss Tools 3 Developers Guide

Pentaho Reporting 1.0 for Java Developers
Pentaho Reporting 1.0 for Java Developers

Moodle 1.9 for Teaching 7-14 Year Olds: Beginner's Guide
Moodle 1.9 for Teaching 7-14 Year Olds: Beginner's Guide

Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software