Note:

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

Roles

From MoodleDocs

Roles and capabilities are planned to be included in Moodle 1.7. For now, we have some basic ideas of how to implement such a structure in Moodle.

Please note that none of the following is finalised.

Definitions

By roles, we mean an identifier of the user's status, for example, teacher, student and forum moderator are examples of roles.

A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, forum_canreadpost is a capability.

The existing system

Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.

The new roles and capability system

The new system will allow authorized users to define an arbitrary number of roles. Each role can have a customizable set of capabilities in every context. A context can be the whole Moodle site, a course, or a module instance, e.g. quiz 5 in 'Introduction to Photography'. An authorized user will be able to assign an arbitrary number of roles to each user. Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to prevent a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to post. This role should have a priority higher than that of a normal 'student' role.

To facilitate exceptional cases in roles and capabilities, we can use exception rules. For example, we can specify a rule saying that all students are able to mark/read other students' assignment in this particular course. Note that such rules need to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.

The plan

There are a few major things that need to be done. Here's a list (in no particular order):

  1. Identify permissions required for site/course/each module.
  2. Define the database structure for storing roles and capabilities.
  3. Recode the whole of Moodle, including all modules to support the new structure. Instead of using isteacher() or isstudent() we should be using has_capabity($capability, $instanceid) etc. A new API for handling roles and capabilities will be implemented (accesslib.php).
  4. Add storage of capabilities for each module. Can be done either in a file, e.g. db/capability.xml, or as a sql file that gets installed to a central db whenever this module is installed. Either way, what do we do when we need to upgrade these capabilities? Some capabilities might needs refining/splitting later on. How do we control the 'version' of a capability?
  5. Consider interface issues, especially how to manage conflicting role/exception rules.
  6. Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?
  7. Consider the impact on backup/restore.
  8. Upgrade path for current users. The user information in table user_coursecreators, user_admins, user_teachers, and user_students will most likely be migrated to the new roles and capabilities tables. The users will most likely be assigned default roles that comes with default capabilities (e.g. teachers, admins, students, etc). The old tables themselves could possibly be dropped at the end of the upgrade.

Capabilities

This is a comprehensive list of capabilities, well, in the making. Please edit. Should we distinguish canedit and candelete?

Site-level Capabilities

  1. canreadblogs
  2. canpostblogs
  3. candeleteallblogs
  4. canbrowseuser
  5. canviewhiddenactivity
  6. cancreatecourse
  7. caneditownprofile
  8. caneditallprofiles

Course-level Capabilities

  1. canseecoursecontent
  2. caneditcourse
  3. cancreatebackups
  4. canrestorebackups
  5. cancreateblocks
  6. caneditblocks
  7. candeleteblocks

Module-level Capabilities

  1. Assignment
    1. assignment_canadd
    2. assignment_canedit
    3. assignment_candelete
    4. assignment_cansubmit
    5. assignment_canmark
  2. Chat
    1. chat_canadd
    2. chat_canedit
    3. chat_candelete
    4. chat_canparticipate
  3. Choice
    1. choice_canadd
    2. choice_canedit
    3. choice_candelete
    4. choice_canparticipate
  4. Database
    1. database_canadd
    2. database_canedit
    3. databaes_candelete
    4. database_canaddentry
    5. database_canaddtemplates
    6. database_canedittemplates
    7. database_candeleteownentry
    8. database_candeleteallentry
  5. Exercise
    1. exercise_canadd
    2. exercise_canedit
    3. exercise_candelete
  6. Forum
    1. forum_canadd
    2. forum_canedit
    3. forum_candelete
    4. forum_canreadpost
    5. forum_canstartnewdiscussion
    6. forum_canreply
    7. forum_caneditallpost
    8. forum_candeleteallpost
  7. Glossary
    1. glossary_canadd
    2. glossary_canedit
    3. glossary_candelete
    4. glossary_canaddnewcat
    5. glossary_canadditem
  8. Hotpot
    1. hotpot_candd
    2. hotpot_canedit
    3. hotpot_candelete
  9. Label
    1. label_canadd
    2. label_canedit
    3. label_candelete
  10. Lams
    1. lams_canadd
    2. lams_canedit
    3. lams_candelete
  11. Lesson
    1. lesson_canadd
    2. lesson_canedit
    3. lesson_candelete
    4. lesson_canparticipate
  12. Quiz
    1. quiz_canadd
    2. quiz_canedit
    3. quiz_candelete
    4. quiz_cantake
  13. Resource
    1. resource_canadd
    2. resource_canedit
    3. resource_candelete
  14. Scorm
    1. scorm_canadd
    2. scorm_canedit
    3. socrm_candelete
  15. Survey
    1. survey_canadd
    2. survey_canedit
    3. survey_candelete
  16. Wiki
    1. wiki_canadd
    2. wiki_canedit
    3. wiki_candelete
    4. wiki_canstartnewwiki
    5. wiki_canparticipate
  17. Workshop
    1. workshop_canadd
    2. workshop_canedit
    3. workshop_candelete
    4. workshop_canparticipate

Scenarios

This section is for brainstorming some example roles that we would like to support:

Parent

Please add text here...

Manager

Please add text here...

Weekly Seminar Leader

In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.

Mentor/Mentee

Please add text here...

Community-Designed Rating Criteria

The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?

Visitor

This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant.

Former Student

This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?

See also

Retrieved from "https://docs.moodle.org/dev/index.php?title=Roles&oldid=2880"
Powered by MediaWiki