CMS Made Simple Forums

Fellow module builders,

When preparing an upgrade for a module, I had the idea to look a bit deeper into the security settings of the module I'm working on.
Some permission settings should be added (no problem I would just prepare a CreatePermission line in the upgrade php).
I leave alone if I need to change at this moment.
However I found that if I earlier had prepared some, for me nice sounding, permission and I want to remove it (either via the upgrade or the removal of the complete module), I could without knowing it, remove the permission of another module as well.
Let's take as example that my module has templates. In the install program I've used 'Modify Templates' with CreatePermission. No problem probably, since a check will be done for earlier existance (I've not checked this). Next step that I take is to remove the unistall the module. This would have as one of the statements RemovePermission. Hmmm, well 'Modify Templates' would be removed as well. But wait a minute, this is also the setting for the designer group. Without checking up front I have removed a large part of the security.
Either the table permissions should be extended with the module name (as from GetName()) or every module builder needs to use a prefix or some unique code in the name of the permission.

Especially with the growing number of modules this might lead to problems for end users/implementors.

What do you think would be a good solution to this.

Duketown

I agree....the CreatePermission and RemovePermission methods need work.

a) Primarily because of the issue that you specified.  A module can remove a core permission, or a permission of another module.  So some type of 'ownership' needs to be associated with things.

b) Additionally, there's the issue of language specification... currently the label for the language is always in English...

Problem 'a' can be solved, though we have to use significant care with the upgrade and install process.  (how do we know on upgrade which module a permission came from). 

I'm not sure how to do anything with problem 'b'.  any ideas?

I would say that the acronym used when requesting a new project in the forge is unique. As an example material for such a module can be found via: http://dev.cmsmadesimple.org/projects/googlemaps.
googlemaps is the (in this case quite readable acronym). If in the module permission is set up, the following could be done (proposal): There will be no second parameter anymore. In the list of permissions, per permission the description could be retrieved via modules\googlemaps\lang\en_US.php with 'googlemaps_maintain_maps' as array entry. If user has a different language, \googlemaps\lang\ext\nl_NL.php would give the dutch translation of 'googlemaps_maintain_maps'.
I have no idea how much performance this would cost. Since this is backend, it might be not that much of a problem.
[edit]Using this notation format, would the permissions neatly be sorted by name and all the permissions for a specific module would 'sit' together.[/edit]

Btw calguy: good thinking on the translations.

With regards to upgrade situations, core comes first and next administrators will have to request module developers to come as soon as possible with an update of the software. I think there is no alternative that will not cause any upgrade problem. I hope I'm wrong in thinking this.

Duketown

calguy1000 wrote: b) Additionally, there's the issue of language specification... currently the label for the language is always in English...

Good idea - second that.

If I'm right there are some modules which supports permission label translations (Statistics?). Have seen it some times ago on my translation work.