On the wiki it is said that normal nodes are overwritten by specific nodes such as server= or world=
This makes sense, and seems to not work for me in some situations.

I have a group (default) and i wish people to not use griefprevention.createclaims in the nether or end, so I negate this node and add a specific node to true for world=world, This works as you would expect, however, for voter ranks i have griefprevention.createclaims true for both world=world_nether and world=world_the_end when a user has both vote4 (parent of vote4 (vote3) houses the nodes for this issue) and default, this does not behave as explained and the user cannot use the permission in the end or the nether.

All vote ranks have a higher weight than default.

Thanks in advance!

Edit: It seems if a rank that has a higher weight than vote3 that inherits default is added to that player, it will overwrite the specific node in vote3, is this intended? because default doesn't have a higher weight than vote3.

Edit 2: It seems even when i add a group that contains these permissions to vote3 it still inherits the weight of vote3 and not the new group with a ridiculously high wight (100000)
So there is no temp fix for this for me ._.

I believe negate permissions will always take priority. Instead of negating the permission in world_nether and world_the_end. Just set the permission for world.

More specific permissions should always take priority. So this seems to be a bug.

This is still happening on latest release, seems to be how the groups are calculating permissions in general.

Sorry for the delayed reply - could you give me a small example I can test with? I can't really follow your explanation above.

Ideally something like:

set permission.x to true, permission.x to false in context world=world, observe true result when checking permission.x (bug)

Ok, so the fault is this

Group Default has 'permission.x' set to false
Group Default has 'permission.x' set to true in world = world
This has the behavior that x is only true in world;

In a higher group such as vote3 i have permission.x set to true in both world nether and world_the_end
The above does not work, the permission check returns false.

I can't reproduce this.

Groups setup as follows on a completely clean setup (this is exactly as you described above):

>lp group default permission set permission.x false
[14:47:25 INFO]: [LP] Set permission.x to false for default in context global.
>lp group default permission set permission.x true world=world
[14:47:36 INFO]: [LP] Set permission.x to true for default in context world=world.
>lp creategroup vote3
[14:47:46 INFO]: [LP] vote3 was successfully created.
>lp group vote3 setweight 10
[14:47:52 INFO]: [LP] Set weight to 10 for group vote3.
>lp group vote3 permission set permission.x true world=world_nether
[14:48:28 INFO]: [LP] Set permission.x to true for vote3 in context world=world_nether.
>lp group vote3 permission set permission.x true world=world_the_end
[14:48:31 INFO]: [LP] Set permission.x to true for vote3 in context world=world_the_end.

Then testing with /lp check Luck permission.x from the console:

Player in default group & in world world:

[14:53:28 INFO]: [LP] Permission check result on user luck for permission permission.x: true

Player in default group & in world world_nether:

[14:54:41 INFO]: [LP] Permission check result on user luck for permission permission.x: false

Player in default + vote3 group & in world world_nether:

[14:55:08 INFO]: [LP] Permission check result on user luck for permission permission.x: true

Corresponding verbose output from this test:
https://luckperms.net/verbose/#diae8ExIt0

Seems to be working entirely as expected.

Please make sure your vote3 group has a higher weight than default - I suspect that may be what the issue is. :)

The server we (third party, Tau, and I) run seems to have it functioning as expected. No clue if this is because of either one of the other 2 having changed how our groups are or what's up, but it's functioning (Proximyst is in the nether; could also use the permission in practice):

I'd say it's likely a configuration error on our end which we've fixed at some point without realising.

Ok great!