Development:Roles

Roles and permissions will be in Moodle 1.7 and are available in the developer version of Moodle.

Definitions

A role is an identifier of the user's status in some context, for example, teacher, student and forum moderator are examples of roles.

A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example, mod/forum:replypost is a capability.

A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.

A context is a "space" in the Moodle, such as courses, activity modules, blocks etc.

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

Template:Moodle 1.7The new system will allow authorized users to define an arbitrary number of roles (eg a teacher)

A role consists of a list of permissions for different possible actions within Moodle (eg delete discussions, add activities etc)

Roles can be applied to users in a context (eg assign Fred as a teacher in a particular course)

Here are the possible contexts, listed from the most general to the most specific.

1. CONTEXT_SYSTEM
2. CONTEXT_PERSONAL
3. CONTEXT_USERID
4. CONTEXT_COURSECAT
5. CONTEXT_COURSE
6. CONTEXT_GROUP
7. CONTEXT_MODULE
8. CONTEXT_BLOCK

An authorized user will be able to assign an arbitrary number of roles to each user in any context.

Capabilities can have the following permissions:

1. CAP_INHERIT
2. CAP_ALLOW
3. CAP_PREVENT
4. CAP_PROHIBIT

If no permission is defined, then the capability permission is inherited from a context that is more general than the current context. If we define different permission values for the same capability in different contexts, we say that we are overriding the capability in the more specific context.

Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by enforcing the rule that the capability defined for a more specific context will win, unless a prohibit is encountered in a less specific context.

For example, Mark has a student role at course level, which allows him to write into a wiki. But Mark also got assigned a Visitor role at a module context level (for a particular wiki) which prevents him from writing to the wiki (read only). Therefore, for this particular wiki, Mark will not be able to write to the wiki since the more specific context wins.

If we set a prohibit on a capability, it means that the capability cannot be overridden and will always have a permission of prevent (deny). Prohibit always wins. For example, Jeff has a naughty student role that prohibits him from postings in any forums (for the whole site), but he's also assigned a facilitator role in "Science forum" in the course Science and Math 101. Since prohibit always wins, Jeff is unable to post in "Science forum".

Allow and prevent will cancel each other out if set for the same capability at the same context level. If this happens, we refer to the previous context level to determine the permission for the capability.

This may sound more complex than it really is in practice. The upshot is that the system can be flexible enough to allow any combination of permissions.

Upgrading from 1.6

A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the existing capabilities will be automatically retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, mirroring what we have in 1.6. With no modifications, Moodle will operate exactly the same before and after the upgrade.

Teachers

Users who were teachers will be assigned the default legacy teacher role (or non-editing teacher role) in all courses they were teacher.

Students

Users who were students will be assigned the default student role in all courses they were student.

Guests

There will still be a single guest user with no default role at site level. For each course that allows guest access, the guest role will be assigned to the guest user for that course context. The guest control for the course will be modified from three to two options (guests always need to enter enrolment key - on/off). This setting is checked as now to force guests to enter key.

Capabilities

This will be a comprehensive list of capabilities (it's not complete yet). It is important that capability names are unique.

Core-level Capabilities

Moodle core capability names start with 'moodle/'. The next word indicates what type of core capability it is, and the last word is the actual capability itself. The capabilities for the Moodle core are defined in lib/db/access.php

1. moodle/legacy:guest - legacy capabilities are used to transition existing users to the new roles system during the upgrade to Moodle 1.7
2. moodle/legacy:student
3. moodle/legacy:teacher
4. moodle/legacy:editingteacher
5. moodle/legacy:coursecreator
6. moodle/legacy:admin
7. moodle/site:doanything - special capability, meant for admins, if is set, overrides all other capability settings
8. moodle/site:config - applicable in admin/index.php and config.php (might break down later) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()
9. moodle/site:readallmessages - reads all messages and history
10. moodle/site:approvecourse - approves a pending course
11. moodle/site:manageblocks - adding/removing/editing blocks (site, course contexts only for now) : 1)_add_edit_controls moodleblock.class.php
12. moodle/site:backup - can create a course backup : 1)course/category.php 2)block_admin.php
13. moodle/site:restore - can restore into this context : 1)course/category.php 2)block_admin.php
14. moodle/site:import - can import other courses into this context : 1)block_admin.php
15. moodle/site:accessallgroups - able to access all groups irrespective of what group the user is in
16. moodle/site:accessdb - directly accessing db (phpmyadmin)
17. moodle/site:viewfullnames - able to see fullnames of other users
18. moodle/site:viewreports - able to view site/course reports
19. moodle/site:trustcontent - ability to use trusttext feature and bypass cleaning in specific areas
20. moodle/blog:view - read blogs
21. moodle/blog:create - write new blog posts
22. moodle/blog:manageofficialtags - create/delete official blog tags that others can use
23. moodle/blog:managepersonaltags - create/delete official blog tags that others can use
24. moodle/blog:manageentries - edit/delete all blog entries
25. moodle/course:setcurrentsection - mark course section
26. moodle/course:create - create courses : 1)course/edit.php 2)course/category.php 3)course/index.php
27. moodle/course:delete - create courses : 1)course/category.php
28. moodle/course:update - update course settings
29. moodle/course:view - can use this to find participants
30. moodle/course:viewparticipants - allows a user to view participant list
31. moodle/course:viewscales - view scales (i.e. in a help window?) : 1)course/scales.php
32. moodle/course:manageactivities - adding/removing/editing activities and resources (don't think it makes any sense to split these)
33. moodle/course:managescales - add, delete, edit scales, move scales up and down : 1)blocks/block_admin.php 2)course/scales.php
34. moodle/course:managegroups - managing groups, add, edit, delete : 1)course/groups.php 2)course/group.php
35. moodle/course:managefiles - manage course files and folders
36. moodle/course:managequestions - manage course questions
37. moodle/course:reset - able to reset the course
38. moodle/course:visibility - hide/show courses : 1)course/category.php
39. moodle/course:activityvisibility - hide/show activities within a course
40. moodle/course:viewhiddenactivities - able to see activities that have been hidden
41. moodle/course:sectionvisibility - hide/show sections
42. moodle/course:viewhiddensections - view hidden sections
43. moodle/course:viewcoursegrades - views all grades in course
44. moodle/course:managegrades - manages grades settings in course
45. moodle/category:create - create category : 1)course/index.php
46. moodle/category:delete - delete category : 1)course/index.php
47. moodle/category:update - update category settings (sort and rename) this is currently an admin capability : 1)course/category.php
48. moodle/category:visibility - hide/show categories : 1)course/index.php
49. moodle/user:viewusergrades - view your own, or other user's grades (with specified context)
50. moodle/user:create - create user : 1) user/edit.php
51. moodle/user:delete - delete user : 1) admin/user.php
52. moodle/user:update - update user settings : 1) user/edit.php
53. moodle/user:viewdetails - view personally-identifying user details (e.g. name, photo). This ties in with the "visitor" scenario described below.
54. moodle/calendar:manageownentries - create/edit/delete
55. moodle/calendar:manageentries - create/edit/delete
56. moodle/role:assign - assign roles to users
57. moodle/role:override - can override role capabilities (depending on context)
58. moodle/role:manage - create/edit/delete roles, set capability permissions for each role
59. moodle/question:import - imports questions (course level?) - Yes, question permissions currently need to be course-level.--Tim Hunt
60. moodle/question:export - exports questions (course level?)
61. moodle/question:managecateory - add/delete/edit question categories (course level?)
62. moodle/question:manage - add/edit/delete a question (course level)

User-level Capabilities

1. moodle/user:readuserposts -read individual user posts on profile page (parent?)
2. moodle/user:readuserblogs -read individual user blogs on profile page (parent?)
3. moodle/user:viewuseractivitiesreport-read individual activity report on profile page (parent?)
4. moodle/user:editprofile - edit profile (normally used in CONTEXT_USERID and CONTEXT_SYSTEM)

Module-level Capabilities

The capabilities are cached into a database table when a module is installed or updated. Whenever the capability definitions are updated, the module version number should be bumped up so that the database table can be updated.

The naming convention for capabilities that are specific to modules and blocks is 'mod/mod_name:capability'. The part before the colon is the full path to the module in the Moodle code. The module capabilities are defined in mod/mod_name/db/access.php.

1. Assignment
   1. mod/assignment:view- reading the assignment description
   2. mod/assignment:submit - turn assignment in
   3. mod/assignment:grade - grading, viewing of list of submitted assignments
2. Chat
   1. mod/chat:chat - allows a user to participate in this chat
   2. mod/chat:readlog - allows a user to read past chat session logs
   3. mod/chat:deletelog - allows a user to delete past chat logs
3. Choice
   1. mod/choice:choose - make a choice
   2. mod/choice:readresponses - read all responses
   3. mod/choice:deleteresponses - deletes all responses
   4. mod/choice:downloadresponses - download responses
4. Database
   1. mod/data:readentry - reads other people's entry
   2. mod/data:writeentry - add / edit and delete (own) entries
   3. mod/data:managetemplates - add, delete, edit fields and templates
   4. mod/data:manageentries - edit/delete all entries
   5. mod/data:comment - comment
   6. mod/data:managecomments - edit/delete all comments
   7. mod/data:rate - rate an entry
   8. mod/data:approve - approves an entry
   9. mod/data:uploadentries - batch upload of entries
5. Exercise
   1. mod/exercise:assess
6. Forum
   1. mod/forum:viewforum
   2. mod/forum:viewdiscussion
   3. mod/forum:viewdiscussionsfromallgroups
   4. mod/forum:viewhiddentimedposts
   5. mod/forum:startdiscussion
   6. mod/forum:replypost
   7. mod/forum:viewrating
   8. mod/forum:viewanyrating
   9. mod/forum:rate
   10. mod/forum:createattachment
   11. mod/forum:deleteownpost
   12. mod/forum:deleteanypost
   13. mod/forum:splitdiscussions
   14. mod/forum:movediscussions
   15. mod/forum:editanypost
   16. mod/forum:viewqandawithoutposting
   17. mod/forum:viewsubscribers
   18. mod/forum:managesubscriptions
   19. mod/forum:throttlingapplies
7. Glossary
   1. mod/glossary:view - read entries
   2. mod/glossary:write - add entries
   3. mod/glossary:manageentries - add, edit, delete entries
   4. mod/glossary:managecategories - create, delete, edit categories
   5. mod/glossary:comment - comment on an entry
   6. mod/glossary:managecomments - edit, delete comments
   7. mod/glossary:import - import glossaries
   8. mod/glossary:export - export glossaries
   9. mod/glossary:approve - approve glossaries
   10. mod/glossary:rate - rates glossary
   11. mod/glossary:viewrating - view ratings
8. Hotpot
   1. mod/hotpot:attempt - attempt a hotpot
   2. mod/hotpot:viewreport - review and view reports
   3. mod/hotpot:grade - (grade? and) regrade
   4. mod/hotpot:deleteattempt - deletes attempts
9. Label
   1. none
10. Lams
    1. TBD
11. Lesson
    1. mod/lesson:view
    2. mod/lesson:edit - add and edit pages
    3. mod/lesson:manage - view student attempts
12. Quiz
    1. mod/quiz:grade - comment, override grade, manual grade
    2. mod/quiz:preview - previews the quiz
    3. mod/quiz:viewreports - view quiz result reports
    4. mod/quiz:manage - add/delete/move (up or down) questions for a quiz
    5. mod/quiz:attempt - attempt the quiz--Tim Hunt
13. Resource
    1. mod/resource:view
14. Scorm
    1. mod/scorm:view
    2. mod/scorm:viewgrades
15. Survey
    1. mod/survey:download - downloads survery result
    2. mod/survey:participate - participate/ do survey
    3. mod/survey:readresponses - read all user's responese
16. Wiki
    1. Waiting on new wiki
17. Workshop
    1. mod/workshop:view - basic capability neede to enter workshop
    2. mod/workshop:participace - original student, allows use to submit and assess
    3. mod/workshop:manage - original teacher, user can manage others
    4. (Waiting on new Workshop)

Enrolment-level Capabilities

The naming convention for capabilities that are specific to enrolment is 'enrol/enrol_name:capability'. The enrolment capabilities are defined in enrol/enrol_name/db/access.php.

1. Authorize.net Payment Gateway
   1. enrol/authorize:managepayments - manage user payments, capture, void, refund, delete etc.

Blocks

1. activity_modules
   1. None
2. admin
3. admin_2
4. admin_bookmarks
5. blog_menu
6. blog_tags
7. calendar_month
8. calendar_upcoming
9. course_list
10. course_summary
11. glossary_random
12. html
13. loancalc
14. login
15. messages
16. news_items
17. online_users
18. participants
19. quiz_results
20. recent_activity
21. rss_client
22. search
23. search_forums
24. section_links
25. site_main_menu
26. social_activities

Questions

I am adding question categories here because they seem to have been forgotten in the whole scheme of things since having been removed from the quiz module itself. I've made a suggestion on how these could be handled in bug 6118.

See this forum thread for a discussion about the current problems wth publishing question categories.Tim Hunt 18:50, 8 August 2006 (WST)

Programming Interface

Although the Roles system may look complicated at first glance, implementing it in Moodle code is fairly simple.

• You need to define each capability once, so that Moodle can upgrade existing roles to take advantage of it. You do this in an access.php inside the db folder of any module (eg see mod/forum/db/access.php). The array contains entries like this (note the descriptions for the legacy roles which provides forward compatibility):

   'mod/forum:viewforum' => array(
       'captype' => 'read',
       'contextlevel' => CONTEXT_MODULE,
       'legacy' => array(
           'guest' => CAP_PREVENT,
           'student' => CAP_ALLOW,
           'teacher' => CAP_ALLOW,
           'editingteacher' => CAP_ALLOW,
           'coursecreator' => CAP_ALLOW,
           'admin' => CAP_ALLOW
       )
   ),

• To load/change these capabilities you need to bump the module version. There's no need to provide changes or differences as Moodle will scan the whole array and sort it out.
• On each page you need to find the context the user is working in, using the get_context_instance() function. For example, in the forum module:

 $context = get_context_instance(CONTEXT_MODULE, $cm->id);

• Then, whenever you want to check that the current user has rights to do something, call has_capability() like this:

   if (!has_capability('mod/forum:viewforum', $context)) {
       print_error('nopermissiontoviewforum');
   }

• If you just want to assert a capability and then finish with an error message if it's not met (as we did above), then a shorter way it to use require_capability() like this:

   require_capability('mod/forum:viewforum', $context);

• Note that there are extra parameters you can specify to get a custom error message, otherwise users get an automated "No permissions" message that lists the permission they were missing.

As a result of the new Roles System, all calls to isadmin(), iscoursecreator, isteacheredit(), isteacher(), isstudent(), and isguest() will have to be replaced with calls to has_capability() or require_capability(). However, these functions will be retained for some backward compatibility with old code, using the legacy capabilities to try and work out what to do.

Problem areas we are working on

Student view

The "Student view" button has been removed completely.

If there is time and a secure way can be found, it will be replaced by a menu to let the user assume a temporary role in the context of that course.

Teacher forum

Teacher forums were always a curious exception to normal forums, as they were not part of a course as such, and were not backed up.

We're taking the opportunity to rectify this. The upgrade converts teacher forums with content to normal forums in section 0 of the course, and ensures that only teachers can access them. If the teacher forum had not been used in the course then it's not converted and will just dissappear.

Enrolment plugins

Process of logging in

(more soon)

Process of checking access to a course

require_login($course->id) is called by the script and has logic like this:

1. Is the user a guest at site level?
   1. Yes: Does the course allow guests?
      1. Yes: return true (and further capabilities are checked by the script)
      2. No: send the user to course/enrol.php for enrolment
   2. No: continue below

1. Does the user have moodle/course:view in that (course) context?
   1. Yes: then they can enter (and further capabilities are checked by the script)
   2. No: is guest access allowed on the course?
      1. Yes: assign temporary guest role to that user for that context (in session cache).
      2. No: send the user to course/enrol.php for enrolment.

Process of enrolling

(more soon)

Scenario brainstorming

This section is for brainstorming some example roles that we would like to support. Note some of these *may* not be possible in 1.7.

Student

Has this one been missed?

Site Designers

Is there a role for people involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.

Educational Authority Adviser

Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.

Educational Inspector

Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.

Second Marker / Moderator

A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.

Peer observer of teaching

Many institutions encourage peer observation of teaching, to encourage reflection on practice. In online environments this will be similar to moderation or inspection. The peer observer would need to be able to experience the course "as a student", but also to be able to view summaries of usage, transcripts of interactions (forums/surveys/polls etc), grades assigned (e.g. in assignments).

External Examiner

Has all the rights of inpectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.

Parent

A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.

In Early Years (EY=3+4 yr olds) and Key Stage 1 (KS1=5+6 yr olds) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary. In Key Stage 2 (KS2=7-11 yr olds) parents would be more monitoring but may join in as well.

In Key stages 3 (KS3=12-14 yr olds) and 4 (KS4=15+16 yr olds) this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.

In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments. Also in all Key Satges there may be a home-school agreement which may be signed up to. Could this form part of a site policy system that incorporates a tickable list of activities the parent agrees to the child using (blogs/wikis/forums etc.)?

Parent's evenings often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.

In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face.

The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.

In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.

Again in the UK, parents have their own independent right of access to a child's educational records. Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.

There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.

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.

Guest Speaker

This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have "guest speakers" who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.

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?

===Alumnus=== An ALUMNUS should be able to search for all other ALUMNI of the school, interact with them and be enrolled in a seperate course - which is like a META course with all the content of his learning and interaction - as well as capabilities to be a part of this ALUMNI only course. All the teachers of courses during school years should automatically be a part of the ALUMNI course .. which means when an ALUMNUS is enrolled in a course, the original teachers of all his courses get enrolled ? --Anil Sharma 20:54, 15 July 2006 (WST)

Librarian

Reference Librarians have an active role in most of the courses taught at some schools such as Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.

In schools there is often a book review system. This may be covered by the lending system database but may not in which case a librarian may neeed to have a course area they can create a database template to handle the reviews in which case they may have a normal teacher style role? Off topic but course an integration with common schools database systems would be great.

Teacher

Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.

I think that what is needed is a simple heirarchy of permissions and levels of granularity.

I would take issue with "teachers should have read access to other teacher's courses unless explicitly prohibited." This is a violation of the students' privacy as how they perform and what they do in one class isn't the business of another teacher. Moreover, in the real world a teacher wouldn't suddenly go sit in on a colleague's class without asking permission first. I would not have appreciated such an invasion of privacy as either a teacher or a student. It could be an option, but shouldn't be default.--N Hansen 19:54, 12 June 2006 (WST)

Community Education Tutors/Trainers

Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.

Secretary/Student Worker

We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.

Teaching Assistant

Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker

Student - FERPA rights

A student that has asserted their FERPA rights to non-disclosure. Typically includes not publishing their name in any public place. Could include this student only being seen with an "alias" within course spaces. Is this an attribute rather than a role?

Help Desk

Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy of inheritance is needed, full access will be problematic with FERPA.

Admin - Catgory based

Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add site-wide entries to the calendar etc.

PROCESS ROLES

organising the learning process for a group you wish to have the choice to place students in differnt roles: examples of this are:

1. Give a student the role of forum-moderator with edit and chunk-rights

2. Give students different roles & rights in a Webquest design (and change these roles next week

3. Give students different resources, depending of their roles in a rolegame/simulation

4. Give a student the rights to create the section content of next week (and only that week..)

5. ..

See also

• Using Moodle Roles and Permissions architecture forum discussion