Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Roles use cases: Difference between revisions

From MoodleDocs
No edit summary
Line 73: Line 73:
*# 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.)
*# 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.
* 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==
==Justification for other parts of the system==

Revision as of 10:38, 10 March 2009

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.

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

TODO

Why you need the Block contexts

TODO

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:

  1. The course will contain 6 graded activities (quizzes, assignments, etc.)
  2. Students are divided into separate groups, each containing 6 students.
  3. For each activity, one student will be selected to grade the work of their peers.
  4. 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:
    1. Create a Grader role, with capabilities like 'mod/quiz:grade' and 'mod/quiz:viewreports' set to Allow, and 'mod/quiz:attempt' set to prevent.
    2. 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:

has_capability($capability, ...);

Developers need to know all the people with a particular capability for reports

That is, we need an API something like the current;

get_users_with_capability($capability, ...);

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

Usability

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.

See also