This is been bugging our adming staff at the OU for years, and it has finally got to the point where we need to do something about this.
So, I have come up with a proposal for a better way to implement this feature: http://docs.moodle.org/dev/Module_security_improvements
Comments please. In particular, a comment from HQ about whether they would like this in 2.3 if I code it.
Petr, there is an existing feature Admin -> Security -> Module security (http://docs.moodle.org/22/en/Managing_activities#Module_security) which I agree is a really bad name.
That is why, in my proposal, I have given it a new name, and moved it from Admin -> Security to Admin -> Plugins -> Activity modules -> Restrict availability (and Advanced features).
Drat! I have just realised there is a potential name-confusion with Conditional availability. Is that a real concern? Can anyone think of a better name?
I agree that this functionality could be achieved with new capabilities (one new capability for each type of module), but then it would be much harder to administer this.
Our main use case is this:
With my proposal, you just need to
With roles, what you have to do is similar
My goal is to make things easier for our administrators. My proposal achieves that much better than using capabilities. It is also closer to the existing functionality.
You know, I keep hoping that one day I will win a technical argument with Petr about some techincal aspect of Moodle, but I don't think it has happened, yet, and it hasn't happened now. Petr, being right is a very infuriating way for you to win every argument
OK, capabilties it is then.
However, steps 1 - 3 in my "With roles, what you have to do is" instructions are really painful for our admin staff.
I think what we really need is an admin tool where you can choose any capability, and then see and edit what the permissions for that capability in all the role definitions. I can, of course, implement such a tool plugin, and it will be useful in other cases.
The only use-case this does not cover is the one were we want to try some dodgy plugin that does not provide a mod/pileofrubbis:addinstance capability - and we don't want to edit the code to define the capability before installing it on our system - OK. That is never going to happen. But my proposal did handle that case.
I wrote this up: http://docs.moodle.org/dev/Module_security_improvements#Proposal_two
Obviously, new admin tool can start in contrib.
Removing all the old Module security code should be 2.3 only.
But, what are much chances of getting the new addinstance capabilities into the 2.2 stable branch? Naughty, I know, but it would be very convenient for us at the OU, just in terms of source-code management.
Would the new screen to change the setting for one capability across all roles also allow multiple capabilities to be changed across all roles? (*)
For example use the filter
'mod/*:addinstance' or a even simpler version ':addinstance', which would show all the ':addinstance' capabilites in the/a multi-select-box and then being abel to select some or all of them.
This would allow you to change the settings of several modules at once.
Anne.
(*) Yes I know I asked a similar question, just wanted to make sure
We thougth about this, and then decided it was better to make the change the setting for one capability across all roles focussed on doing just that. Once capability at a time. It is simpler and safer.
If someone wants a different sort of admin tool plugin, they are welcome to build one - they can even start from my code, once I have written it. It is all GPL.
I like the idea of using capabilities but it would be nice if this was an "automatic" core capability that just exists for all blocks/mods/ other plugins as defined. - is there an elegant way we could do this without needing to modify each plugins /db/access.php ? - the upgrade process could trigger a message to say the plugin doesn't implement the capability so it's been added automatically?
I think debugging message on install is the way to go for now.
The other cap that most mods are recommended to have is mod/whatever:view. Do we have debugging warnings if that is missing yet?
I like Dan's idea. And I believe the implementation is not that hacky actually. Something like this:
Just before it fetches the db/access.php files from all mods, the core would pre-populate the $capabilities array with default values for all installed modules. Something like
foreach ($modules as $module) {
$capabilities["mod/{$module}:addinstance"] = array(
/// default cap spec here
}
}
Just after this, it would include modules' access.php files. So the module can overwrite the default capability definition if it has a good reason for it (for example it deactivates itself by default). If there is no explicit definition in the module, the default definition is used.
This way we get the support for the capability in all modules, including the contrib ones.
I think it could be easily allowed for any plugin/subplugin-type base directory (/mod, /blocks, /theme, /mod/workshop/form...) so it can have one db/commonaccess.php file to be processed and containing all the caps to be populated.
Perhaps we could, also, make those directories proper subsystems (note that a lot of them are already, manually), so perhaps adding the results of get_plugin_types() to get_core_subsystems() can be a good idea too.
Ciao
About the new, interesting proposed improvement, my preference definitely goes towards using capabilities rather new admin settings. While admin settings may have is pros, capability can give roles the granularity needed to address many scenarios at different context levels. My+1 for working with capabilities .
Just so I'm clear (as I may have contributed to the confusion )
The proposed 'setting defaults caps for all modules, allowing the modules to overwrite them', is a seperate issue, right?
If so, can that part of this thread be 'forked/branched' into a new one?
Anne.
Yes, capabilities did win
Even though it means (if I understood correctly) that there is no longer a default setting as proposed in Proposal 1.
And the cap vs role edit screen Tim suggests would also be a welcome addition I think.
As an added benefit it would also show how a specific cap 'tricles-down' through the different roles.
If you could even make it possible to bulk-edit more than one capability at a time that would make admin a lot easier i think.
The proposal 2 speaks of " each type of activity module in Moodle core".
Is there a reason to limit this to activity modules and only Moodle core module?
Anne.
If I want to implement this, I have to submit a patch for all the core modules. Changes to contrib modules are up to the people who maintain those modules.
I agree that it should be the responsibility of the people maintaining the non-core modules, it's their code to start with.
But... from an admin POV it would be interesting to at least have the ability to also have this (these) capabilities created for existing 3rd part modules.
That would allow an admin to restrict access to an old and forgotten module that you do not want creators to use in new courses.
Anne.
Petr asked for more feedback from Admins:
Wehad several discussions from admins to give different groups of teachers different access to tools. It would make it much easier for teachers starting with Moodle to get access to a limited set of activities/blocks/admin functions and to give them more options if they have some experience and ask for more.
It should also be possible to give them access based on participation on some trainings: step 1: ressource+forum; step 2: assignment + quiz; step 3:....
The definition which feature is connected to which role should be configurable locally.
We also discussed about course category based permissions if departments have different needs. But this can be organized by roles also.
The easiest way and the method I use is. New teachers to Moodle are put in the none editing class of teacher. They can't break anything or, create content but most of the other functions are available.
Once they gain confidence I give them there own sand box usually a personal classroom to break and experiment in. After that full teaching privileges.
The capability approach sounds best to me in regards to restricting adding modules/blocks.
On that note, Tim's idea for side by side viewing of all the roles setting for a given capability is a very good idea and would save alot of time when comparing/settingup roles (especially when combined with a :addinstance approach to module restriction). Core or otherwise, it'd be a handy tool to have.
As a fix for the existing feature this proposal sounds perfect, but I have to say that the prospect of being able to apply this at the course category level, which the capability-based solution would give, is very appealing!
At our university we've identified a need to be able to make modules available to whole departments or faculties while hiding them from others (for example, our computer science department are intending to create some very subject-specific tools for Moodle, which we're happy to install, but we don't want them cluttering up the activity list of the humanities faculty). For this kind of use case, the administration of the capabilities wouldn't be particularly onerous as it would be done once at a category level. In general, though, I'd agree that having to use roles and capabilities to administer this would be much worse for the end user than the proposed solution.
If you need a new name for it, Admin -> Plugins -> Activity modules -> Restrict adding' would do and is more accurate.
I like the proposal, but I also think the other option, implementing a 'mod/*:addinstance' capability for all modules would probably be fine too - as far as I can see this should work for OU as well.
Our main use case for this feature is that we have a module which we do not support in general - for example, the Workshop module - so we want to prevent course staff from adding it. (In a system as large as ours, just telling them not to add it won't work.) But we want it to be available for piloting on a particular course or courses. As far as I can see, we could achieve that using capabilities.
Another note: whichever way this is implemented, it would also be really nice if it could apply to blocks also.
--sam
Note: sorry for double-post, this was because cloudflare gave an error so I hit reload. Twice. (But I managed to delete the third copy.)
Why not "Restrict modules"? This also works for "Restrict blocks".
"Retrict adding" misses out vital information.
For moving and renaming.
I have now written the code, and it is waiting for peer review. See MDL-19125 for details.
If anyone does have time to peer-review this, I would be most grateful.
