UI for capabilities in the module context

UI for capabilities in the module context

by Jamie Pratt -
Number of replies: 7
Hi roles experts,

The Problem

I notice that the roles and capability UI does not allow capability overrides at the module level for any capabilities besides mod/{modulename} capabilities and moodle/site:accessallgroups.

The new question capabilities in Moodle 1.9 ( 'moodle/question:add', 'moodle/question:editmine' , 'moodle/question:editall' , 'moodle/question:viewmine' , 'moodle/question:viewall', 'moodle/question:usemine', 'moodle/question:useall', 'moodle/question:movemine', 'moodle/question:moveall') should be overridable at CONTEXT_SYSTEM, CONTEXT_COURSECAT, CONTEXT_COURSE and CONTEXT_MODULE context levels. For CONTEXT_MODULE ideally the capabilities should only be overridable for modules that use questions.

It is only CONTEXT_MODULE that they are not showing up in.

Should We Make the Capabilities Visible In the Roles and Capabilites UI?

Should we maybe add these capabilities to fetch_context_independent_capabilities()??

Or Should We Make the Capabilities Overridable Via the Update Activity Module Form?

An alternative method I was thinking of to make these capabilities overridable is to allow them to be overriden through use of the Update Activity form. In fact I think that a few options for combinations for question access capabilities would be better for most cases instead of having full access to all the question capabilities at the module level at least.

Jamie


Average of ratings: -
In reply to Jamie Pratt

Re: UI for capabilities in the module context

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
A third solutions would be to make a new function in the module API - something like 'mod_get_relevant_capabilites', that returns an array capabilities, in addition to the ones specifically for this module, that should be overridable for instances of this module.

Then, in this case, make a function in questionlib.php called 'question_get_relevant_capabilites' that gets all the capabilites required by modules using questions, that quiz_get_relevant_capabilites, and qcreate_get_relevant_capabilites can call to avoid duplicating code.
In reply to Tim Hunt

Re: UI for capabilities in the module context

by Jamie Pratt -
Yeah I'd be willing to implement that.

For the question creation activity I think it would be nice to be able to have a simplified interface in the Update Module form where you can choose from a few common combinations of capabilities but have full access to all the question capabilities on the Roles Override page.

Roles gurus - does something like 'mod_get_relevant_capabilites' seem sensible to you?
In reply to Jamie Pratt

Re: UI for capabilities in the module context

by Ray Lawrence -
I've not had chance to think this through fully but my initial reaction is that this:

  • Approach blurs the module settings / roles settings boundary at module level.
  • Conflicts with the logic of having an "Allow role overrides" interface where admins determine who can override roles.
  • Mixes up question bank options with module options (I've not looked at the new QB stuff in 1.9 beta in detail so this may be yesterday's thinking).


In reply to Ray Lawrence

Re: UI for capabilities in the module context

by Jamie Pratt -
Hi Ray,

Thanks for your thoughts.

Quick reply to your 3 points :

  • "Approach blurs the module settings / roles settings boundary at module level." Having a simple UI for permissions in the module update form does do this but has the advantage of making setting up some common capability combinations quick and easy. I propose to have the two UIs work in parrallel with each other. The qcreate modules update module form part would be disabled if more complex overrides have been done under the Roles tab.
  • "Conflicts with the logic of having an "Allow role overrides" interface where admins determine who can override roles." I guess the module update form can respect these permissions and not allow someone who doesn't have permission to override roles to set up a question creation activity.
  • "Mixes up question bank options with module options (I've not looked at the new QB stuff in 1.9 beta in detail so this may be yesterday's thinking)." Question bank options are module options. See Question_permissions and Question_contexts
In reply to Jamie Pratt

Re: UI for capabilities in the module context

by Ray Lawrence -
Having a simple UI for permissions in the module update form does do this but has the advantage of making setting up some common capability combinations quick and easy. I propose to have the two UIs work in parrallel with each other.

Ok, but having one UI for this in Quiz and another for the remaining modules is simply bad news IMO. If this was the beginning of a more general refinement of setting capabilities and permissions that would be better.

The qcreate modules update module form part would be disabled if more complex overrides have been done under the Roles tab.

I'm having problems visualising this as a clean logical interface. Let's not forget that many, many teachers work with the interface and roles that are presented to them, they have little or no knowledge (or interest) in the finer points of the site's set up. We can't assume that a given role will have access to role overrides, or access to role overrides for roles that may be impacted upon by the "simplified" module page UI.
In reply to Ray Lawrence

Re: UI for capabilities in the module context

by Jamie Pratt -
By the way "mod_get_relevant_capabilities" would be just an addition to the current roles and permission logic to allow modules to specify some extra capabilities that should be overridable in their context. The stuff about having a simplified UI for capabilities editing in the Question Creation Modules update form is really a separate discussion.
In reply to Jamie Pratt

a new optional function in mod/*modname*/lib.php '*modname*_get_relevant_capabilites' that returns an array of capabilities.

by Jamie Pratt -
I created a new issue in the tracker for this feature. MDL-11421