Permissions not listed in plugins.yml
SlimeDog opened this issue · 16 comments
EssentialsX-2.0.1-b579 and previous
Permissions are not listed in plugins.yml. Among other things, this means that they are not exposed to the LuckPerms permission tree builder.
Please list the permissions for each command.
And to add further to this, the new permissions for EssentialX isn't in the old permission reference site
http://wiki.mc-ess.net/doc/permissions
A bit confusing to search for them sometimes...
@SlimeDog - I've been using LP with Essentials for quite a few releases and haven't seen any issues with permissions not showing in LP. I'm assuming the permission tree builder you are referring to is the editor?
I went back to 551 and looked thru to 580 and the plugins.yml permission section hasn't changed. Perhaps that is part of the problem that something else should be listed and isn't? I'm happy to test other scenarios to help the EssX Team.
Essentials has never listed them (afaik) in the plugin.yml so tab complete and other things won't function properly. Perhaps we should start doing that? :)
https://github.com/EssentialsX/Essentials/blob/2.x/Essentials/src/plugin.yml
possibly. I don't know what the "standard" recommended practice is for what to include in the plugin.yml, but seems like it makes sense to add the commands and permissions to this file so permission plugins like LuckPerms can be integrated better (for this issue).
I spot checked some of the more popular resources I have and most of them included the commands (where they had them and permissions) in the plugin.yml.
Examples can be seen in Dynmap, MassiveCore, CreeperHeal, CreativeGates, PlaceholderAPI, Residence and WorldBorder. Perhaps intentional, LuckPerms doesn't list its permissions in the jar.
@SlimeDog - I've been using LP with Essentials for quite a few releases and haven't seen any issues with permissions not showing in LP. I'm assuming the permission tree builder you are referring to is the editor?
I was referring to the output of (at the console)
lp tree
Yes, because since they are not included in plugin.yml, they are not registered with LuckPerms until requested.
I did see examples of some plugin.yml's where they used a wild card to cover any child node. I think the intention was just to get them registered, but seems like that could cause performance issues if they all get added or potential conflicts.
A bit off topic, but what determines the order of permissions and its priority order? I know all the wildcard's xxx.* get added to the top of the stack, but are all the others done alphabetically? Just curious so I can understand better the implementation challenges. :-)
@smmmadden (In reference to your off-topic point) For permissions plugins, I believe that it's just the order in which they get added as PermissionAttachments. Bukkit's source of having the default: sections added from the plugin.yml as PermissionAttachments would likely give you a more exclusive answer.
Keep in mind commands aren't loaded until used as well. So the commands and permissions effectively don't exist until used. This is how the project was originally written to 'lazy load' things, one of the benefits is allowing other plugins to take priority if there are any conflicts.
A bit off topic, but what determines the order of permissions and its priority order? I know all the wildcard's xxx.* get added to the top of the stack, but are all the others done alphabetically? Just curious so I can understand better the implementation challenges. :-)
That sort of specific ordering is a permission plugin implementation detail. The Bukkit implementation applies in the order of:
- child permissions from attachments (aka permission plugin + plugin.yml)
- regular permissions (aka provided permission plugin)
- child permissions from defaults (aka plugin.yml permissions section)
- defaults (aka anything granted to everyone in the plugin.yml)
and permission plugins overriding Bukkit (such as PEX, LP etc) should also provide the same behaviour. (although some don't!)
Back on topic:
Among other things, this means that they are not exposed to the LuckPerms permission tree builder.
only some of the permission nodes are showing up
haven't seen any issues with permissions not showing
Just thought I'd point out that the reason you're seeing inconsistent results here is because the tree / tab completion data is built over time. As only a few permissions are recorded in the Ess plugin.yml, the tree will be initially small, then expand over time as players use Essentials commands & features, and LP is able to detect and record the checks occurring.
You can (kinda) simulate this by running /help - to trigger permission checks for each command - to produce a more complete tree.
In my experience, plugins generally don't register their permissions in the plugin.yml file, unless they have a reason to (i.e. they want to set it them to be granted by default) - mainly I'd guess because it's a hassle to maintain, for no major benefit. 😄
I'm not super familiar with the code layout in Essentials - it might be easier to register permissions programatically (perhaps when commands are init'd). Could be worth the effort if it's just a small diff 😛
I find the tree useful, but the objective of this issue was not to create unnecessary work for the devs. So perhaps a less-obtrusive approach is for me (and other operators who like these data) to generate the LuckPerms tree after the server has been running as long as possible, in order to benefit from programmatic additions of permissions. Plan B: construct a command script that executes a lot of (Essentials and other plugin) commands, then generate the tree.
Since I cannot contribute to the code base (trust me, you don't want my meager Java skills in there), I will personally be working on Plan B. I am willing to do the work to gain a benefit.
Thanks @lucko that's more detail than I was reading here: https://bukkit.gamepedia.com/Developing_a_permissions_plugin :-) I'm one to dig into the mechanics of how something works and why it works the way it does which is part of what I do for work as well.
It sounds like the plugin.yml while it may contain some of the permissions, there is nothing currently available to pre-load permissions for one-to-many-to-all plugin permissions before they are called and there isn't a real value statement for doing it.
Other than seeing it in LP Tree display or the editor which is useful, but doesn't necessarily improve the use of the game and both have limits in what it can write out. Any server with a lot of mods and a large number of permission nodes won't see all listed in either. I've got 20 mods on my test server and all that shows in 991 lines (48,110 characters) is LuckPerms & Nucleus and I don't see all of the latter. This may just be wasted effort to include something that doesn't necessarily provide what was needed.
It would be nice if someone could create a plugin/mod that could do just that. Write out (to a file) all the available permissions that can be used by all the available mods loaded and indicating which permission nodes have been explicitly configured and which ones have not. As a server owner, we know that docs get behind and new features/permissions/commands are added all the time and they get out of sync but the code itself lives on the server and it should be current. That's life in this business. I think that's really the issue, right @SlimeDog ?
