LuckPerms

LuckPerms

41.4k Downloads

Registered permissions displayed in editor/tree are all lowercase

jhenhapl opened this issue ยท 5 comments

commented

Description

When displaying registered permissions from plugins, they are all printed in lowercase. Since permissions are case-sensitive, this is not a good idea. Users can easily get confused when the permissions selected from the given list don't work because of unshown uppercase characters.

Reproduction steps

With /lp tree [plugin], the tree of permissions are all lowercase
With /lp editor, the suggested permissions are all lowercase

Expected behaviour

The permissions should match exactly what Permission#getName returns and not the lowercase string.

Environment details

  • LuckPerms version: v5.2.35

Any other relevant details

commented

Since permissions are case-sensitive

Not for LP, no. LuckPerms doesn't discriminate all lowercase permission nodes from others. Independently of the platform, LP makes the asked permission lowercase to compare against the stored ones which are also lowercase.
This is precisely to avoid capitalization issues.

The only cases I can think off the top of my head where nodes (not necessarily permission nodes) are case sensitive is chat nodes (prefix/suffix), meta nodes and group display name.

commented

My plugin makes use of user-given permissions that get registered on-demand. When checking if a player has the set permission, it is returning false when I add the lowercase permissions suggested by LuckPerms. When I add the case-sensitive version, it works.

commented

How are you checking for the permission in your plugin?

commented

I construct the permission string, register the permission, then use Permissible#hasPermission with the constructed string.

It may fix it to check if they have the registered permission instead of the string but this may be something that developers (including myself) will overlook.

EDIT: I have confirmed that checking the actual Permission object vs the String works. However, I still believe this could lead to confusion with plugins that check String-based permissions instead of registered ones.

commented

This may be resolved by the above commit.

If not, would you mind putting together a minimal test case which demonstrates the issue? I'd be happy to take a look. :)