Adding permissions from plugin-info.xml

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Adding permissions from plugin-info.xml
« on September 19th, 2012, 03:28 AM »Last edited on September 19th, 2012, 03:51 AM
I mentioned yesterday that I would have to look at this, and well, here we are.

This is, interestingly, absolutely required in the long term, so I might as well do it now.

Problem 1: unless permissions are declared in the plugin-info.xml file, there's no way for the system to automate cleanup when removing a plugin. This would be more of a problem if it weren't for problem 2.

Problem 2: even if you declare permissions in your plugin's settings page (using the permissions option or similar), there is a possibility that the main manage-permissions code can remove them again because they're not part of the main permissions code as well.

Consequently, we actually have to declare permissions and add them to the main permissions area, even if you keep all the settings in the plugins area like I've been doing. It sucks, but given the rest of the architecture that's actually the best way to go forward.

What it does mean is that you do need to actively declare your permissions, regardless of anything else. And if you really want to do complex stuff, you can still use the hooks that are there, but you must ALWAYS declare permissions in the plugin-info.xml file.

Even if you're doing byzantine stuff like declaring permissions guests can't have, which isn't in the plugin-info.xml file but only accessible via the hook to keep the structure lean, you still have to put the bulk of permissions stuff in plugin-info.xml.

Here's what the structure will look like - simplest case, like I've added for topic solved.

Code: [Select]
<newperms filename="lang/TopicSolved-Permissions">
<permissionlist>
<permission type="membergroup" name="topicsolved" ownany="true" classic="general" simple="view_basic_info" />
</permissionlist>
</newperms>

Anyone who's added SMF permissions should recognise all the components of that ;) In case people haven't... let me break it down.

<newperms> is the overall container. If that block isn't found, there's no permission processing to do. If it is, there should be a filename entry, which should cover the language file which contains all the strings for that plugin's permissions.

<permissionlist> is the container for all the permissions. There is another container I'll get onto in a moment.

<permission> declares a new permission. Type is membergroup or board, for whichever it is, name is the core permission name. ownany declares whether it is an own/any permission or not, and if it isn't, the name will be the actual name for allowedTo() tests. Otherwise it'll be the permission + _own and _any, just like in SMF.

classic indicates which group it will be added to in Classic View, simple for Simple View, just like in SMF. I may yet rip this stuff out, don't know yet.

If you need to add a whole new group of permissions, you can do so by also adding the groups container.

For example, if I had wanted to make a new section for Topic Solved entirely, I could have done so with:

Code: [Select]
<newperms filename="lang/TopicSolved-Permissions">
<groups>
<group type="membergroup" column="right" classic="ts_group" simple="ts_group" />
</groups>
<permissionlist>
<permission type="membergroup" name="topicsolved" ownany="true" classic="ts_group" simple="ts_group" />
</permissionlist>
</newperms>

All the $txt requirements (i.e. what all these should be named) is entirely unchanged from what it is in SMF.

This looks cumbersome but it actually is no more than you'd have written making permissions in SMF (and this is simpler in practice, you just declare it and it works)
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial