Roles and permissions

I just wanted to muse on our issues with the moodle/view:courses and the assumption in the Moodle codebase that these equates to a course enrolment.

We have a couple of role use cases that this affects:

1) We want all our logged in users to be able to view any course unless the tutor has said guests aren't allowed. Access for non-logged in guests i.e. the Moodle guest users should be controlled separately. i.e. a tutor should be allowed to decide whether they will allow anonymous guests, logged in users not enrolled on their course or neither. By default we want logged in users to see courses so they can make module choices and get course materials until their module choices are reflected via the student record system as enrolments.

To do this we create a previewer role which has the same capabilities as our student role except cannot view grades, take assignments, quizzes or choices.

2) Departmental Administrators need editing access to all courses in their department category without appearing as tutors. We call these non-teaching editors so are the reverse of non-editing teachers. We assign these at category level.

The problem is both these roles need the moodle/course:view capability to provide access to courses but this then causes problems as by having this assignment they are often assumed to be course participants. As our Preview role is the role assigned by default by logged in users this often means that all our users (over 13,000) are considered course participants.

This has causes problems in areas like:

- the My Courses Block (users see every course)
- backups with users (all siste users are included)
- users who haven't responded to a choice (all site users are displayed)

I thought this might be an example of the kind of issues you get when your business roles require you to twist Moodle in unusual ways but I'm really interested to visit the forums and see that others are challenged by this problem:

http://moodle.org/mod/forum/discuss.php?d=107267
http://moodle.org/mod/forum/discuss.php?d=106274

The issue is that has_capability(moodle/course:view)is often used in place of an explicit role assignment check in a context. So the code doesn't derive course participation from role assignment but the presence of a capability in that context. Because the contexts are hierarchical and has_capabilty checks recursively up the entire context hierarchy then role assignments at a higher level i.e. category or system include these users.

My plea to the developers is to try and break this relationship between being a course participant and having the moodle/course:view capability in some way to allow for roles that are assigned this capability in contexts above course level allowed without them being considered a course participant. Perhaps by checking explicit role assignment instead, only checking for the moodle/course:view capability in the course context when used to determine course participants, or making the capability used to determine course participants configurable rather than hard coded as this constrains custom role configurations.

It is of course possible that what we want to do with our roles could be achieved in other ways that wouldn't incur this problem and any approaches to this would be welcome (or maybe not now that I can't change what we've done this academic year anyway!). We also wanted to minimise the use of overrides in specific contexts - how fussy are we??

The lightest touch approach we have taken to fix these issues (although it does involve modifying core files which again we aren't keen on) is to create a configuration value $CFG->courseusercap and replace the use of moodle/course:view with this in places where it has caused us a problem. We've then set the value of $CFG->courseusercap to a capability that we allow for students/teachers but not for our other roles.

I'm not sure this is a great solution but it is a workaround that seems to have resolved most of our problems at the moment.

We're going to do an architecture review of our Moodle install this year so we may rethink how we do things, but I just thought I'd add our experience to the discussions on the use of course view capability within Moodle in case it helps other Moodlers and also provide the developers with an example use case.

Regards,
Alison