Description

When comparing permissions in 3 different ways, the results are inconsistent.

Yaml file

Full file: https://paste.bnn.gg/operator.yml

Editor

Link: https://luckperms.net/editor/fcHndu47IJ

Command

I've run /lp sync and rebooted the server but nothing changed.

Reproduction steps

I don't have enough time to test if it can be reproduced on a fresh server, sorry

Expected behaviour

I should see the same list of permissions whether I'm editing the yaml file, using the web editor, or viewing the permissions ingame with commands.

Actual behavior

Each medium shows a different set of permissions. Searching e.g. grep -Rni "group.seniorstaff" . within the yaml-storage/groups/ folder yields no results, but it should be right above health.set in the operator.yml file

Environment details

Does LuckPerms create the permission group.<group> internally?

How is it inconsistent?
The group.builder is shown as false in yaml, as well as command (node is red). For the editor screenshot you didn't show the value section so it's impossible for us to tell.

EDIT: From the editor link, it shows the node is set so false as well...

To add on, if are talking about health.set, it is present in all 3 screenshot as well. If you mean the order of the nodes, it's probably not possible/practical to be exact same order due to difference in the way the sort/display nodes and how code map works.

Parent groups are not stored as group.<group> permissions in (text based) storage, they are stored as <group> under parents, that's why they don't (and shouldn't) show on .. permission info when you properly add a parent group, but rather in .. parent info.

Additionally, setting a parent group "permission" to false doesn't "remove" the parent group as many people think.

Besides, the way it shows in storage does not necessarily have to match what you see in the web editor nor what you see in commands, in those cases it is meant to be human readable and interpretative, which may not be the case for the underlying storage.

This may be where we are confused about each other's answers. I created the group.x permissions when I was on PEX, it is not intended to have anything to do with LuckPerms' groups.

I do have my parents set up correctly, that is not an issue, I guarantee. But if LuckPerms is automatically adding group.x permissions based on its own internal group structure, that answers my question about where the perms were coming from, considering I don't have group.seniorstaff defined anywhere in the yaml file structure.

Understanding this, I can understand that the yaml file can be different than the editor and the ingame viewer, but I don't understand why the editor and the ingame viewer are different from each other. Shouldn't they both display the same calculated group.x permissions?

You can see in your own YAML that parent groups have their own section and are not treated as regular permissions:

parents:
- architect
- moderator
- seniorstaff

To be honest I don't know where that group.builder set to false came from as a permission in storage. Maybe if you set the node to false in the editor it does that (especially since it's the only one)? That's something subject to test and, kind of another issue if that's the case.

I don't understand why the editor and the ingame viewer are different from each other. Shouldn't they both display the same calculated group.x permissions?

They kind of are and kind of aren't, the web editor has its own little section for parent groups:

Would be some sort of "equivalent" to the parent info command, not exactly because it doesn't show contexts or expiry date like the command does, and I believe that may be the reason why it is also shown as a node in the web editor because, like any other permission, it can have contexts and an expiry date.

Feel free to make a suggestion either in this repo (the main plugin) or in the LuckPermsWeb repo (I personally think this would be more of a suggestion for the LPW project, I like it there being a distinction between parent groups and regular permission nodes like commands show 😛) or wait until Luck reads all this and comes up with a conclusion :)

Yes and no, they are stored in a special, separate "map"/collection they are put into alongside the regular permissions collection, that's why they are not like other regular permissions and are not shown when you run the permission info command if you add the parent group properly (either with the parent set/add command or from the web editor).

I would love if I could disable the feature that calculates these permissions so I can define them myself

Absolutely impossible. That would break so incredibly much. Especially with plugins interfacing with LP.
I'd recommend you scope your own permissions.

Now even if we ignore the practical issues with implementing this as setting, it means support hell. There are already so incredibly many obscure config setting for edge cases that can really mess up an instance if changed carelessly. Adding another one will just be such a pain to debug if people inevitably enable it.

While I absolutely agree with you that the permissions should have been scoped, it's way too late now to change it.

I'm not sure you're following, as I mentioned, my group.x permissions were created back in PEX, and imported into LuckPerms. Until today I had no idea LuckPerms calculated the group.x permissions itself, I thought parents simply controlled the inheritance, now I understand they also create a new permission. That is why I have group.builder: false in my config, I manually created it when creating my own group permissions years ago. Accidental name conflict.

I would love if I could disable the feature that calculates these permissions so I can define them myself, assuming it doesnt serve some internal purpose (in which case, maybe you could provide a way to re-scope it? e.g. luckperms.group.x)

I'm still confused about the differences between the command and the editor; why doesn't group.moderator or group.architect show up in the command? what makes it different from group.seniorstaff? group.builder makes sense, I have it explicitly defined as false, but the other 3 are not defined anywhere in the yaml structure, yet one behaves differently.

Erm, yeah, sorry, I don't think there's much I can do about this at this stage. The group.x format has been used by LP since the start, it's not easy for me to move to something else now. Sorry.