Support fine-granular control over managing of certificate element instances and certificate instance attributes

This issue supersedes #137 and #181.

Currently, mod/customcert:manage controls multiple aspects of this activity plugin. If a user has mod/customcert:manage, he is allowed to do whatever he needs with a certificate instance. However, there is no possibility for fine-granular control who should be allowed to do what.

Step 1a: Add a new capability mod/customcert:managepage which controls if a user is allowed to set or update the page attributes width, height, left margin and right margin or not.

Step 1b: Make sure that all areas of the plugin which deal with setting or updating the page attributes, especially /mod/customcert/edit.php, respect this capability and prevent a user action if necessary.

Step 2a: Add an internal flag to the element subplugins to store if an element instance has been loaded from a global template or if the element instance has been created within the certificate instance.

Step 2b: Make sure that all areas of the plugin which deal with loading templates into an activity instance or with creating an element instance within an activity instance set this flag appropriately.

Step 3a: Add a new capability mod/customcert:createlocalelements which controls if a user is allowed to create element instances within the element instance.

Step 3b: If a user has mod/customcert:createlocalelements, he will be able to create element instances within the activity instance as he is able now. If a user does not have mod/customcert:createlocalelements, he won't be able to create element instances within the activity instance. Make sure that all areas of the plugin which deal with creating element instances, especially /mod/customcert/edit.php, respect this capability and prevent a user action if necessary.

Step 4a: Add a new capability mod/customcert:managelocalelements which controls if a user is allowed to update and delete element instances which have been created within the element instance.

Step 4b: If a user has mod/customcert:managelocalelements, he will be able to update and delete element instances which have been created within the activity instance. If a user does not have mod/customcert:managelocalelements, he won't be able to update or delete element instances which have been created within the activity instance. Make sure that all areas of the plugin which deal with updating or deleting element instances, especially /mod/customcert/edit.php, /mod/customcert/edit_element.php and /mod/customcert/rearrange.php, respect this capability and prevent a user action if necessary.

Step 5a: Add a new capability mod/customcert:createloadedelements which controls if a user is allowed to load the element instances provided by a global template into an activity instance.

Step 5b: If a user has mod/customcert:createloadedelements, he will be able to load global templates into the activity instance as he is able now. If a user does not have mod/customcert:createloadedelements, he won't be able to load global templates into the activity instance. Make sure that all areas of the plugin which deal with loading templates into an activity instance respect this capability and prevent a user action if necessary.

Step 6a: Add a new capability mod/customcert:manageloadedelements which controls if a user is allowed to update and delete element instances which have been loaded from a global template.

Step 6b: If a user has mod/customcert:manageloadedelements, he will be able to update and delete element instances which have been loaded from a global template. If a user does not have mod/customcert:manageloadedelements, he won't be able to update or delete element instances which have been loaded from a global template. Make sure that all areas of the plugin which deal with updating or deleting element instances, especially /mod/customcert/edit.php, /mod/customcert/edit_element.php and /mod/customcert/rearrange.php, respect this capability and prevent a user action if necessary.

Step 7a: Add a "Fixed element" checkbox setting to each element subplugin to control if an element is fixed or changeable.

Step 7b: Add a new capability mod/customcert:managefixedelements which controls if a user is allowed to create, update and delete fixed element instances or not.

Step 7c: The mod/customcert:managefixedelements is preceded by customcert:createlocalelements / customcert:managelocalelements / customcert:createloadedelements / customcert:manageloadedelements capabilities which define if the user is generally allowed to do a particular action. Only if he is generally allowed, the additional check for mod/customcert:managefixedelements will happen. If a user has mod/customcert:managefixedelements, he will be able to create element instances as he is able now. He will be able to set or unset the "Fixed element" checkbox setting within an element instance. And he will be able to update and delete existing element instances, regardless if the "Fixed element" checkbox setting is enabled or not. If a user does not have mod/customcert:managefixedelements, he will be able to create element instances as he is able now. However, he won't be able to set or unset the "Fixed element" checkbox setting within an element instance. And he won't be able to update and delete existing element instances if the "Fixed element" checkbox setting is enabled. Make sure that all areas of the plugin which deal with creating, updating or deleting element instances, especially /mod/customcert/edit_element.php and /mod/customcert/rearrange.php, respect this capability and prevent a user action if necessary.

Step 8: Now, the ordering of existing element instances isn't under any new capability control yet. It can be discussed if the ability to order elements will also be coupled to mod/customcert:managepage or if it would make sense to add another dedicated capability for that purpose.

Step 9a: Now, mod/customcert:manage will probably still be there in the code as an omnipotent capability. All checks for mod/customcert:manage should be replaced by checks for a more fine-granular capability which has been added in the above steps. If during these replacement any use case arises which isn't yet covered by a new capability, this gap has to be evaluated and handled.

Step 9b: Within a plugin upgrade script, all existing roles which own mod/customcert:manage should get all of the new capabilities to retain their current ability to do their stuff.

Step 9c: The mod/customcert:manage capability should be removed from the plugin.

Hi @markn86,

based on our recent call, I have created this specification and would appreciate any feedback from you.

Even if I would be able to pursue it in the near future, it made sense to me to write it down in a structured way.

Thanks, Alex

Is there any plan to actively work on this proposal?

If not, we would be interesting in coding this (we have developers!) as we want to adopt customcert in our institution but need some of these finer level permissions before doing so (basically we want to lock down the ability to create your own certificate and force use of existing templates - this proposal would enable that and more).

(By the way - 9c mentions removing the manage capability - we still see a use for this, or alternative, for permission to access and manage the system level templates)

Hi @jason-platts ,

I am sorry that I didn't spot your message earlier.

At Ulm University for which I created this issue, we don't have plans to implement this currently as the implementation turned out to be more complicated than estimated initially.

I also don't think that @markn86 will be able to tackle it.

If you have developers and want to step up, please go ahead. Just make sure to synchronize with @markn86 about the approach once more so that the change can be integrated smoothly.

Thanks, Alex