Note: You are currently viewing documentation for Moodle 2.1. Up-to-date documentation for the latest stable version is available here: Roles.

Development:Roles: Difference between revisions

From MoodleDocs
m (formatting, minor re-wording)
Line 1: Line 1:
==Roles and Capabilities==
'''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.


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.
''Please note that none of the following is finalised.''


==Definitions==


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


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, ''can_read_forum_post'' is a capability.


A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, can_read_forum_post 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 Existing Roles and Capabilities System]]
==The new roles and capability system==


Currently in Moodle, we have a fixed set of Roles. For example, we have the primarty admin, admins, course creators, editting teachers, non-editting teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student will allow the user to submit an assignment, but not allowing the user to browse/edit some other user's work. However, 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 all teacher privilages.
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 new Roles and Capability System]]
==The plan==


The new system will allow authorized users to define arbitray 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 arbitray number of roles to each user. Since the capabilities in each roles could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to disallow a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to do any postings. This role should have a priority higher than that of a normal 'student' role.
There are a few major things that need to be done. Here's a list (in no particular order):


To facilitate certain 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 student's assignment in this particular course. Note that such rules needs to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.
#Identify permissions required for site/course/each module.
 
#Define the database structure for storing roles and capabilities.
 
#Recode the whole of Moodle, including all modules to support the new structure. Instead of using <code>isteacher()</code> or <code>isstudent()</code> we should be using <code>has_capabity($capability, $instanceid)</code> etc.
[[The plan]]
#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?
 
#Consider interface issues, especially how to manage conflicting role/exception rules.
There are a few major things that need to be done. Here is just a list, and it's not in any particular order.
#Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?
 
#Consider the impact on backup/restore.
1) Identify permissions required for site/course/each module.
 
2) Database structure for storing roles and capabilities.
 
3) Recoding of the whole Moodle, including all Modules to support the new structure. Instead of using isteacher() or isstudent() we should be using has_capabity($capability, $instanceid) etc.
 
4) 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) Interface issues, esp 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) Impact on backup/restore?


==Scenarios==
==Scenarios==


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


===Parent===
===Parent===
 
''Please add text here...''


===Manager===
===Manager===
 
''Please add text here...''


==See also==
==See also==

Revision as of 10:33, 15 May 2006

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, can_read_forum_post 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.
  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.

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

See also