Description

EssentialsX has an issue here which creates a new permission for every single material in the game with the essentials.hat.preventtype.<material> permission. EssentialsX is yet to include a fix or toggle for this feature.

The sheer amount of permissions that Essentials creates for this purpose cause LuckPerms' web editor to just hit the limit and not show any other permissions past it. That means, all permissions in alphabetical order after essentials.hat.preventtype.PINK_STAINED_GLASS, for example, do not appear in the web editor, and thus can't be assigned to groups.

I understand that you may be thinking.. "hey, this is an Essentials issue, not a LuckPerms issue". You're correct, this specific issue is caused by EssentialsX - however, if other plugins create the same behaviour (new permission spam), then once again this issue will come back. This is why I suggest that LuckPerms has its own solution.

Proposed behaviour

I propose that LuckPerms adds a configuration option which allows the server owner to list whatever permissions they wish.

An asterisk (*) can be used to block any child permissions, such as hello.* would block hello.earth and hello.mars, but not hello.

Here's an example configuration:

web-editor-permissions-bypass:
- 'essentials.hat.preventtype.*'
- 'john.*'
- 'test.permission'
- 'hello'

That example configuration will:

• Block essentials.hat.preventtype.BEDROCK, essentials.hat.preventtype.STONE, etc. It will not block essentials.hat or essentials.preventtype.
• Block john.smith, john.doe, etc. It will not block john.
• Block test.permission, but not test or test.perm.
• Block hello, along with hello.there and hello.goodbye.

Quite unsure how the issue linked above on EssentialsX's issue tracker has not gained more traction, especially considering the large amount of EssentialsX and LuckPerms users who would also be experiencing this issue.

I've done multiple edits to this post in hopes that it is crystal clear of what I am suggesting. If there is anything you didn't understand, please ask - I'm very willing to clarify.

Thank you very much!

The limit has been increased and the way it applies has been altered.
This should no longer be an issue 👍
d83559b

The limit has been increased and the way it applies has been altered.
This should no longer be an issue 👍
d83559b

Thank you very much!

An idea for a slightly more elegant solution; currently the /lp editor command dumps all the needed info (current perm setup & known perms) into a single Bytebin. I wonder if it could be better if, after a preset size of perm nodes, it splits that section off into a second bytebin, where it doesn't have group/user perms also using space. This would cause the editor to become a bit slower to load on both ends (due to 2 requests needing to be made instead of one), but then all perms would be usable in autocomplete. Just a thought.

That means, all permissions in alphabetical order after essentials.hat.preventtype.PINK_STAINED_GLASS, for example, do not appear in the web editor, and thus can't be assigned to groups.

A reminder that permissions can be set via the editor even if autocomplete doesn't have it. Simply type it in.

A reminder that permissions can be set via the editor even if autocomplete doesn't have it. Simply type it in.

Thank you - a few days after opening this issue, I had realised this, although I forgot to mention that here.

I wonder if it could be better if, after a preset size of perm nodes, it splits that section off into a second bytebin, where it doesn't have group/user perms also using space. This would cause the editor to become a bit slower to load on both ends (due to 2 requests needing to be made instead of one), but then all perms would be usable in autocomplete. Just a thought.

That means, all permissions in alphabetical order after essentials.hat.preventtype.PINK_STAINED_GLASS, for example, do not appear in the web editor, and thus can't be assigned to groups.

Your idea sounds solid - one thing, however - I am having trouble connecting why the second bytebin is being sent when its permissions won't appear in the web editor?

Sorry if I was unclear. Background info for those unaware, the backend for the web editor, Bytebin, is just a basic pastebin. Obviously it has a size cap per paste, which is where the problem arises from.

Basically I'm proposing there be 2 pastes sent. The first one will be the known permissions, probably separated by commas, newlines, or maybe a JSON list of strings. The URL of that will be saved, and attached with the second paste, which contains all the other data as normal. When the editor is open, it'll do it's normal load, then once the data is loaded in, it could make a second request to load the second paste, containing the autocomplete.

Since the paste containing the known permissions is separated, it has all the space free that actual set permissions used to take up. Hope that cleared things up.