Roles use cases
This page is an attempt to reverse-engineer the Use Cases that Moodle's roles an capabilities system was designed to satisfy.
Having the use cases written down will make it easier to discuss proposed changes to the system like Role_overrides_revisited or how to resolve issues like MDL-17210. If we agree on what the requirements are, then we can have more meaningful discussions about the advantages of any proposal.
Below, we list both use cases, than then a summary of the current situation in the bullet points.
- 1 General need for a configurable permissions system
- 2 Justification for the various types of context
- 3 Justification for the permission resolution rules
- 4 Justification for other parts of the system
- 5 From the developers point of view
- 6 Usability
- 7 See also
General need for a configurable permissions system
Administrator wants to control who can do what
This is really too broad to count as a single use case, but still it is worth stating. The old system in Moodle 1.6 and before, with seven hard-coded roles was not flexible enough for administrators in all sorts of situations, and there were lots of little code tweaks in circulation.
- Clearly some sort of configurable permissions system was necessary.
Justification for the various types of context
Why you need the System context
An administrator needs to administer the whole site.
- Therefore you need some concept of one user have a role across the whole site.
Why you need the Course category contexts
Administrators want the capability to delegate responsibility for administering some aspects of all the courses in a particuar Faculty/Departement/... to a sub-administrator (e.g. Course Creator role.)
- Therefore you need some concept of one user have a role everywhere in a course category.
Why you need the Course context
We want to be able to say that someone is a student or teacher in a course.
- Therefore you need some concept of one user have a role in a course.
Why you need the Module context
We want to be able to appoint a user as a moderator in a particular forum.
- Therefore you need some concept of one user have a role in a particular activity.
Why you need the User context
Parents want to be able to access their Children's profiles (including forum posts, recent activity, grades, etc.) but cannot be give access to other children's work in the course.
- Therefore you need some concept of one user have a role in relation to another.
Why you need a separate Front page context
Why you need the Block contexts
Justification for the permission resolution rules
TODO, we need lots more here ...
Why we need overrides
We wish to prevent all students from posting in a particular forum.
Why more specific role assignments must take precedence
An instructional designer who fervently believes in Social Constructionism wants to set up a course as follows:
- The course will contain 6 graded activities (quizzes, assignments, etc.)
- Students are divided into separate groups, each containing 6 students.
- For each activity, one student will be selected to grade the work of their peers.
- In the activity that each student will grade, the do not complete the work that the other students do.
- To set this up with the current roles system:
- Create a Grader role, with capabilities like 'mod/quiz:grade' and 'mod/quiz:viewreports' set to Allow, and 'mod/quiz:attempt' set to prevent.
- In the activity each student is supposed to grade, assign them the Grader role. As well as letting the grader grade the other students in their group, it will prevent them from attempting the quiz, because the Grader role assignment is more specific than the Student role assignment in the course, so the Prevent from the grader role takes precedence over the allow from the student role.)
- This would not be possible if the proposal in Role_overrides_revisited was adopted.
Comment: Instead of relying in current fragile mechanism, it would be easier to use take quick prohibit and grade allow in Grader role. In general allowing students to grade is not possible now, because it is associated with XSS risk.
Justification for other parts of the system
People who control sub-areas of a Moodle site should not be able to lock administrators out
That is, someone who can override roles in a course should not be able to prevent Administrators from doing things in the course.
- This is why administrators have the magic moodle/site:doanything capability that trumps all others.
Need a way to let users into a course without being participants
- Not currently possible to let someone into a course, they must have moodle/course:view, but that adds them to the participants list unless either it was a hidden role assignment, or they also have moodle/site:doanything.
From the developers point of view
Developers need to know if a certain operation or access to a certain page should be permitted
That is, we need and API like the current:
Developers need to know all the people with a particular capability for reports
That is, we need an API something like the current;
Developers need to be able to user the list of users with a particular capability in DB queries
For example in an SQL JOIN or something.
- Not currently possible the only option is to get a list of userids from get_users_with_capability and the write SQL like AND userid IN (...)
Different users need to be able to understand those parts of the system they need to use
Roles_administration_improvements_for_Moodle_2.0#Who_are_our_target_users_anyway.3F elaborates on this point.