Module security improvements

Module security improvements
Project state	Code written aiming at 2.3. Waiting for review.
Tracker issue	MDL-19125
Discussion	http://moodle.org/mod/forum/discuss.php?d=196939
Assignee	Tim Hunt)

Moodle has a Module securityfeature, which lets admins control which activities can be added to which courses. This feature has, however, always been problematic. This page first describes the problems with the current system, and then proposes two better ones.

Currently Proposal two is the favoured choice.

Existing problems

1. If you turn this on, on a site where some courses already exist, and ask for "Restrict modules for: requested courses" and turn on "Restrict modules by default", then actually the restrictions are not applied to any of the existing courses.
2. If you create course using some method other than the basic create course admin UI, then the restrictions are not applied. (MDL-11894)
3. In the database, we store a list of all allowed modules for all existing courses (in the course_allowed_modules table), which means that if the admin later wants to change the list of allowed modules, it does not really work. (MDL-19125)
4. Currently, admins get to ignore these restrictions, and edit the list of which modules are allowed in each course. There should be a specific capability moodle/course:manageallowedmodules.

Old admin UI

Old course settings UI

Proposal two

New addinstance capabilities for all modules

For each type of activity module in Moodle core, add a mod/modtype:addinstance capability. Use this to control which types of module a user can add to a course.

New admin tool

Then, because that is a real pain to configure the way we want, (see http://moodle.org/mod/forum/discuss.php?d=196939#p858359) I propose to create a new admin tool that makes it easy to change the setting for one capability across all roles on a single screen.

First you select a capability:

http://tracker.moodle.org/secure/attachment/27070/Alter+roles+by+capability.png

Then you can change the setting for that capability in all roles:

http://tracker.moodle.org/secure/attachment/27076/Alter+roles+by+capability+2.png

The show advanced button lets you access the Prohibit option. Like in the normal roles UI, we will probably use a background tint to show the default setting for each role.

Clean up

Of course, once this is done, all the old 'Module security' code should be stripped out of Moodel 2.3.

Proposal one

There will be a new setting on the Advanced features admin page:

Restrict activity availability: Yes / No

Allow administrators to control which activities can be added to which courses. The restrictions are managed on Plugins -> Activity modules -> Restrict availability, which only appears when you enable this feature. This feature only restricts which activities can be added to a course. Modules that already exist in a course will continue to work, and administrators (those with the moodle/course:manageallowedmodules capability) will still be able to add any activity to any course. If you want to disable an activity completely, you can do that on Plugins -> Activity modules -> Manage activities.

If this setting is off, none of the rest of the UI below will appear.

Proposed admin UI

There will be a new admin page Plugins -> Activity modules -> Restrict availability. This page is only accessible to those with the moodle/course:manageallowedmodules capability

http://tracker.moodle.org/secure/attachment/27057/Possible+admin+interface.png

Proposed course settings

These settings only appear to users with moodle/course:manageallowedmodules capability.

http://tracker.moodle.org/secure/attachment/27059/Possible+course+settings+UI.png

New capability

moodle/course:editallowedmodueslist "Manage allowed modules" - This controls three things

• in the system context, the ability to access and use the Restrict availability admin page.
• in the course context, the ability to see and change the Restrict available activity modules settings.
• in the course context, the ability to add any activity, despite the restrictions.

By default, only the manager role gets this capability.

Really, there are two separate capabilities here (manage the list of what is available, and ignore the restrictions) but

• if you can manage the list of what is available, then you can get round the restrictions anyway.
• if you trust someone enough to let them add any module anyway, then it is only a small step to let them control what other people can add.

So I do no think there is enough benefit in having two capabilities to justify the extra complexity.

Database changes

The course_allowed_modules table would be be changed. At the moment it just has columns (id, course (int), module (int)). This would be changed to (id, courseid (int), module (char), allowed (int)).

• courseid is renamed to match the coding guidelines.
• module is changed to be the module name (forum, quiz, ...) because that is more self-explanatory, and easier for backup and restore.
• allowed this is a new column, that contains +/- 1. This stores per-course settings, but there is now only a row here where the setting in the courses is explicitly Allow or Disallow, not Default. Therefore, we are only storing exceptions to the site-wide policy.

As well as changing the install and upgrade scripts, this will also require changes in backup and restore.

The system level settings will be stored in config_plugins, component 'core_courseallowedmodules'. Name will be the module name ('quiz', 'forum', etc.) The value will be one of 'alwayson', 'defaulton', 'defaultoff', or 'alwaysoff'.

Upgrade

We need to convert the existing settings to the new settings. I think this is doable.

The same logic will need to be used when restoring old backups.

Knock-on effects on the rest of the code

Searching for 'course_allowed_module' - which find both the table name, and the name of the key API function, only returns 15 hits, so it looks like this will be a surprisingly simple change to implement.

Status of this proposal

The old and unreliable UI here has been annoying us at the OU for years. We finally had sufficient justification to propose something better. We would like to implement this for Moodle 2.3.