Standardize on a mechanism for plugins to define permission group presets, like griefprevention:user or nucleus:admin, that minimalizes plugin boilerplate and improves discoverability through the usage of a permission plugin.
There is not currently a standard, idiomatic way for plugins to specify permission presets that server owners can then apply for simplified plugin setup. Every plugin (especially large ones) should be able to provide sane defaults for a minimal setup, without needing to build their own system for it.
The end product should meet the following goals:
- Minimal boilerplate from the plugin developer perspective
- Low feature support cost for permission plugins
- Discoverable through the usage of the permission plugin
From what I can tell over the course of PermissionDescription's life, it is seldom used, because it doesn't add enough value for plugin developers, to make them want to add descriptions for their permissions (server admins can look at the plugin's project page for this information, anyways). By extending the PermissionDescription API to support permission presets, plugin developers may be more willing to document their permissions, especially if they can setup easy defaults for server admins to use.
How are these defaults then applied?
I see two paths, depending on the server admin's preference, using the following examples:
- Admins can make their
usergroup directly inherit from thegriefprevention:userpreset. - Admins can use a copy function provided by the permission plugin to copy all current nodes from the
griefprevention:userpreset into theusergroup.
Example Usage:
@Listener
public void onInit(GameInitializationEvent event) {
PermissionService service = Sponge.getServiceManager().provideUnchecked(PermissionService.class);
service.newPresetBuilder(this)
.role("user") // or use PermissionPreset.ROLE_USER
.add(service.newDescriptionBuilder().id("nucleus.afk.base").build(), true, false)
.add(service.newDescriptionBuilder().id("nucleus.helpop.base").build(), true, false)
// or alternatively(?):
.add("nucleus.home.base", null, true, false)
.register()
}Why have a firstRunOnly option?
- For whenever a plugin wants to send out an update, without giving players new permissions without the server admin knowing. Only clean installs will add these new permissions.
Notable changes:
PermissionPresethas been addedPermissionDescriptions are registered here, with an additional option to only register them during the first run after plugin installation (i.e. only register them when the preset is not yet known to the permissions plugin).- Role Identifiers are namespaced by the supplied plugin; before there was
user, now there isgriefprevention:user, for example.- Useful when a server owner doesn't want to apply all plugins'
userpresets.
- Useful when a server owner doesn't want to apply all plugins'
PermissionDescriptionis now a simple data aggregate of a permission and its (optional) description.- Descriptions are no longer registered directly to the service. Instead they are added to a preset which is then registerd to the service.
PermissionDescription#findAssignedSubjects(String)andPermissionDescription#getAssignedSubjects(String)were removed, as they seem unnecessary (just fetch directly from thePermissionService).
PermissionService#SUBJECTS_ROLE_TEMPLATEhas been replaced withPermissionService#SUBJECTS_PRESET. This naming more accurately describes what the subject collection holds, given the expanded API.
Allow permissions that themselves grant other permissions. This is a nasty solution because it's hidden and implicit.
Have plugins add their own command to grant a given preset type to the specified group. This is a suboptimal solution because it isn't discoverable, and requires a lot of boilerplate.
Have plugins, during permission checks, also check for a general permission representing the preset. This is a suboptimal solution because it's not discoverable.