Roles administration improvements for Moodle 2.0
| Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable. |
Improving the usability of Moodle's Roles system is one of the main targets for Moodle 2.0.
This evolving page summarises a number of proposed changes to these administration interfaces, derived from community suggestions since Moodle 1.7.
We would really like your feedback on:
- the changes already proposed here
- any issues that you feel are not yet addressed
Please join the discussions and post your suggestions in the Roles and Capabilities forum.
Most of this is now done. You can try it out by downloading a recent copy of Moodle 2.0 dev. Anything else will happen if there is time.
Views to help you understand your roles set-up
The roles system is designed to give administrators lots of flexibility in controlling who can do what where. That is, to let administrators control how Moodle answers questions like "Can user Fred reply to posts in the 'Give an example of poor usability' forum?" To understand that question and its answer, you need some key concepts:
- Contexts
- like the "'Give an example of poor usability' forum". These are areas within Moodle, and they are contained within each other, so that forum might be in the Usability course, which is in the Computing category of a Moodle system. You can think of this like folders on your hard disc contained within each other. Things that happen in one context have an effect on all the contexts inside.
- Users
- like Fred.
- Capabilities
- like "reply to posts". These are particular things that users should, or should not, be allowed to do.
- Roles
- Do not appear in the question above, but are important in working out the answer. Users are not given capabilities directly. Instead users are assigned roles, and the Roles give or take away capabilities.
- Role assignments
- A role assignment says a certain user has a certain role in a certain context. This role assignment will have an effect on which capabilities the user has in that context, and every context inside it.
- Role definition and Permissions
- The definition of a role assigns a permission (Not set, Allow, Prevent or Prohibit) to each capability.
- Role overrides
- change the definition of a particular role within a particular context and its sub-contexts by changing the permission associated with some capabilities.
The changes in this section are all about making these concepts more visible, and helping you see how things are set up in your system. Several of them involve taking a cross-section through the settings by fixing one thing and showing how the other things vary. For example for a fixed user and showing all their role assignments, or for a fixed capability, showing all the role definitions and overrides.
Map of where you are in the contexts
On any page to do with roles that relates to a particular context, there should be a "block" on the right of the screen which shows you the current context is within the Moodle system. It would show you the chain of parent contexts, all the way up to the System context, and also what child contexts there are.
[TODO]
User's roles report
This report, available to administrators, lists all the roles assigned to a particular user anywhere in the system and also allows you to remove any of them. This was available as a stand-alone report plugin for Moodle 1.9. In Moodle 2.0, it should be integrated as a tab in the user profile. In the screenshot below, (if you have the necessary permissions) the edit icon takes you to the assign roles page for that role in that context, with this user already selected, so if you want to remove this role assignment, you then just have to click the remove icon. The 'preview' icon takes you to the Check permissions page for this user in the that context.
Capability report
This report, available to administrators, shows you the permissions for one particular capability throughout the system. It shows you the permission set for that capability in the definition of each role, and then everywhere in the system where those permissions are overridden.
Check permissions page
This could appear as an 'Check permissions' tab next to 'Assign roles' and 'Override permissions' to anyone who is allowed to do either of those things. That tab would let you select a user, and then will show you all the capabilities, and whether this user has each one in this context. In addition, there will be an explain link next to each capability, which pops up a detailed explanation of how the user's role assignments combine with the role definitions and overrides to give the answer yes/no to whether the user has that capability, as in John Isner's document How permissions are calculated.
New 'Enrolment details' mode in the participants list
A new mode when looking at the participants list, available to people with the assign roles capability. It includes information about each users roles and group memberships in the table.
Changes to how roles are defined and assigned
Improved widget for selecting users
On pages like assign role and add group members, where you need to select users from one list, and add them to another, the interface for searching for and selecting users has been improved. In particular you will be able to search both the lists of potential users, and the list of people who already have the role or are in the group. The search can now consider any combination of email address, user id number and username, and the search happens automatically when you stop typing, there is no need to click the search button and wait for the page to reload.
Restrictions on which roles can be assigned in which contexts
Normally, it only makes sense to assign a user the role of administrator in the System context; or to assign the Student role in the course context. Therefore, we will add new information to the definition of each role, restricting which sorts of contexts it can be assigned in. This will reduce the irrelevant choices on the assign roles screens.
Search box on the define/override roles pages
The define roles screen lists over 200 capabilities. We can add a search box so that you can type something like 'forum' and just see just the matching capabilities. You can see this in action now in HEAD.
Simplified define/override role page, with show advanced
When defining roles, you normally only need to use the Not set and Allow permissions. We can simplify the interface for defining roles to a single check-box next to each capability instead of the four radio buttons. A 'Show advanced' button would reveal the full four permissions when required. Similarly, on the override roles page, we can hide the Prohibit permission behind a show advanced button, leaving just Inherit, Allow and Prevent.
Also give a face lift to the manage roles page. For example, you can no longer delete the last remaining admin-like role, and when you duplicate a role, it takes you to the role editing form so you can adjust the role before you save it. On the Role allow assign page, rotate the table headings (thanks sam!) so the table is easier to manage.
Prevent changes to the 'do everything' capability
By default, the Administrator role has a special capability 'moodle/site:doanything' that is important for the correct functioning of Moodle. People sometimes get into trouble when they change this setting. Similarly, it not sensible to give this capability to any other role. Therefore, we should make it impossible to change the permission for this capability in the definition of any role.
[DONE]
Don't let administrators unassign the administrator role from themselves
Administrators have never been able to unassign the administrator role from themselves, but since Moodle 1.6 this has been completely unclear from the UI. Now it is clear again.
Terminology changes
This is still subject to debate, but
- Assign roles -> Manage participants, and
- Override permissions -> Adjust permissions
are suggestions that have been welcomed so far.
Other ideas that are not currently scheduled
There are some other ideas that have been suggested in the past, but are not currently scheduled to be included in the 2.0 release, unless we suddenly get extra time. I list them here for reference.
- Import and export of Role definitions: MDL-17081
- Easy way to assign mentors/parents to a lot of users: MDL-17068
- Roles override presets: MDL-9466
- Further improvements to the override roles page.
A way to easily assign one user roles in several contexts?
The Users' roles report (see above) already lets you remove any of a user's current role assignments. We might enhance it to allow you to add new role assignments for a user (however, we really need some suggestions on how this should work).
Who are our target users anyway?
Logically this should come first, because before solving usability problems, it is essential to know who your users are - only then can you tell whether your proposed solutions will help them. However, one of the purposes of this page is to summarise the changes we are making for Moodle 2.0, and I did not want to dilute that by adding more introductory material at the top.
I think there are three key categories of user we have to satisfy:
The teacher who just wants to teach
They need to be able to add Students, Non-editing teachers and perhaps other Teachers to their course with essentially zero training, other than having it mentioned as one of the steps required when setting up your course.
Moodle administrators of a basic site
The typical example here is the teacher who is 'volunteered' to run the school's Moodle site on half a day per week. They don't need anything other than the default roles settings. In addition to what teachers have to be able to do, they also need to be able to assign other Administrators and Course creators, again with minimal effort.
If an administrator like this needs to start doing more, that is, making the transition into the next category of user, we must ensure that they cannot easily shoot themselves in the foot. For example, an administrator should not be able to lock themselves out of the system.
People who want to benefit from roles
The third category is a bit less clearly defined. It is people who need the functionality that roles makes possible. Some examples are
- an administrator who wants to set up a Parent role, or slightly adjust the default roles;
- a teacher or learning designer who wants to set up some interesting sequence of activities with people in different roles;
- an administrator of a major site with significantly non-standard roles requirements.
- teacher who wants to give students the ability to add or edit content within a course, giving students more creative ability to manage their own learning
They key thing here is that these users have a goal of their own, so they have an incentive to start learning about roles. For them, we need to make the learning curve as smooth as possible. For example, if you want a Parent role, you can Google it, and follow the instructions on Parent role. Most of the diagnostic tools I am adding to Moodle 2.0 are aimed at this group, making it easier for them to work things out on their own, helping them get the right conceptual model, and clearly see the consequences of the settings the changes they make.
See also
Related items on the Moodle 2.0 Roadmap
- Site-wide groups
- Enrolment improvements
- Role overrides revisited
Other related links
- MDL-8524 Meta bug tracking a lot of roles improvements.
- Roles and Capabilities forum
