General developer forum

Proposed improvements to the 'Module security' feature

Proposed improvements to the 'Module security' feature

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature
Hi,

why do you call this a security improvement? It seems to indicate that somehow security of modules is improved. This feature restricts adding of new activities, access control for adding of new activity instances to courses.

Did you consider adding new capability for each module such as mod/resource:addinstance instead? I guess it would be a bit more flexible and easier to implement. By default all editing teachers and managers would get these new caps, you could change role definitions or override them at category or course contexts.

Petr

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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:

• We have a new tool we want to add to our live system for pilot use on some courses only.

With my proposal, you just need to

1. Go to the admin page, and set the new activity to 'Some courses', 'Disabled'.
2. Go to the pilot courses, and set the activity to 'Available'.

With roles, what you have to do is similar

1. Go to the define roles page for the teacher role, find the mod/mynewactivity:add capability in the middle of the page and turn it off.
2. Repeat for Course-creator role.
3. (In the OU's case, repeat for about 6 other custom roles)
4. Go to the pilot course(s)
5. Go to override permissions.
6. find the mod/mynewactivity:add capability in the middle of the page and all the different roles you want to be able to add it.

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature
I have to disagree, the fact that it is easier for one OU use case does not mean it is better for everybody all the time. We have role based system, I think we should use it for as much as possible.

I believe simple use cases are more important:.

1. Admins wants to prevent creation of new forums because site migrated to forumng - admin changes role definitions of editing teacher role and removes mod/forum:addinstance from all roles

2. Admin wants to enable contrib hotpots in English language category only - remove mod/hotpot:addinstance from editing teacher role, override capability at one category only.

I believe that the capability based system gives us more flexibility. It may be a bit harder to set-up in some cases, but I think this functionality is not used every day/week and it should not matter much if admin spends 1 minute or 5 minutes setting it up.

Role based solution:
+ less admin config clutter, less course settings clutter (tiny fraction of sites is using this, right?)
+ much easier implementation and future maintenance
+ more flexibility in unusual scenarios

Benefits of Tim's proposal
+ faster to set up in some scenarios
+ it is similar to Moodle 1.6

Average of ratings: Useful (2)
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: Useful (2)
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature
Hehe, capabilities did not win yet, we should imo wait for more feedback from admins, in any case my +1 for improvements like this in 2.3. Thanks a lot for bringing this forward.

Missing plugin caps? I guess it should be possible to define it in some local plugin. It might need some minor tweaking in core to deal with upgrades where you might temporarily get cap duplicates. I guess the easiest way is to just modify older plugins and track the changes in git because it would be painless in future upgrades. We would need to add some debugging info to inform devs anyway.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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?

Average of ratings: Useful (3)
Re: Proposed improvements to the 'Module security' feature

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?

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature
I do not like these core capability defaults at all because it may cause problems in contrib plugins that may introduce the defaults in access.php in some future upgrade. All developers have to periodically update plugin code - the worst case scenario here is that you would not be able to restrict some contrib activity.

Average of ratings: Useful (1)
Re: Proposed improvements to the 'Module security' feature

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

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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 .

Average of ratings: Useful (1)
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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

Average of ratings: Useful (1)
Re: Proposed improvements to the 'Module security' feature

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

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

Why not "Restrict modules"? This also works for "Restrict blocks".

"Retrict adding" misses out vital information.

For moving and renaming.

Average of ratings: -
Re: Proposed improvements to the 'Module security' feature

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.

Average of ratings: -