LuckPerms

LuckPerms

41.4k Downloads

include-global: false not working

selfslaughter opened this issue ยท 7 comments

commented

Setting "include-global" to false, still applies global permissions.... (sometimes)

config.yml Settings:
include-global: false to ignore any global permissions from the other servers.
apply-global-groups: true to still use the existing groups to decide which group to put them in

lp check, lp permission checkinherits etc. all say I should not have the permission in this context, but in game the global permission of true is applied instead.

lp verbose command self_slaughter //wand
[08:52:22 INFO]: [LP] Forcing self_slaughter to execute command //wand and reporting all checks made...
[08:52:22 INFO]: [LP] VB > self_slaughter - worldedit.wand - true
[08:52:22 INFO]: [LP] Command execution complete.

lp check self_slaughter worldedit.wand
[08:52:26 INFO]: [LP] Permission check result on user self_slaughter for permission worldedit.wand: false

lp user self_slaughter permission checkinherits worldedit.wand
[08:52:30 INFO]: [LP] self_slaughter has permission worldedit.wand set to false in context server=vanilla. (inherited from vanilla)

lp user self_slaughter permission checkinherits worldedit.wand server=vanilla
[08:52:34 INFO]: [LP] self_slaughter has permission worldedit.wand set to false in context server=vanilla. (inherited from vanilla)

lp user self_slaughter permission checkinherits worldedit.wand server=
[08:52:36 INFO]: [LP] self_slaughter has permission worldedit.wand set to true in context global. (inherited from user0)

lp user self_slaughter info
[08:52:42 INFO]: [LP] > User Info: self_slaughter
[08:52:42 INFO]: [LP] - UUID: ebef591e-4bac-4ffc-bd8c-f08a584ac3bd
[08:52:42 INFO]: [LP] (type: mojang)
[08:52:42 INFO]: [LP] - Status: Online
[08:52:42 INFO]: [LP] - Parent Groups:
[08:52:42 INFO]: [LP] > user0
[08:52:42 INFO]: [LP] - Contextual Data: (mode: active player)
[08:52:42 INFO]: [LP] Contexts: (server=vanilla) (world=vanilla)
[08:52:42 INFO]: [LP] Prefix: None
[08:52:42 INFO]: [LP] Suffix: None
[08:52:42 INFO]: [LP] Primary Group: user0
[08:52:42 INFO]: [LP] Meta: (weight=110) (primarygroup=user0)

lp user self_slaughter permission checkinherits group.vanilla
[08:52:52 INFO]: [LP] self_slaughter has permission group.vanilla set to true in context server=vanilla. (inherited from user0)

For more specific details: In the above scenario, I have a group called "vanilla" that is set under one of my global "user0" groups as "group.vanilla server=vanilla". Then all permissions inside the vanilla group are set with an explicit server=vanilla context to keep things separate. This all appears to work fine as far as I can tell.

In this case user0 has worldedit.wand true in a global context, but the vanilla group has it set to false, however global permissions still seem to apply and override the server specific ones, even though global permissions should be ignored, and the vanilla group is weighted above all of my global groups as an extra fail safe.

commented

Also, the server also has the following contexts.json so any permissions set from the vanillas console automatically specifies that context.

{
"static-contexts": {},
"default-contexts": {
"server": "vanilla"
}
}

commented

So, it turns out adding a single player directly to the group, rather than just inheriting it in a certain context, suddenly made the whole thing start working as expected and not just using the original groups global permissions when in game.

Removing the player afterwards, so the group has no direct players again and everything is still working as intended. Just needed a player in it temporarily to kick start it.

commented

Apologies I'm a bit confused, is there still an issue or have you figured it out?

commented

Sorry, This one was a bit of a mess, I found a workaround that seems to hold up for now, but there's something amiss initially.

So basically setting a server to ignore global permissions, but then not actually having any server specific permissions set directly (all groups with the server specific permissions were inherited from their main group when in that servers context, rather than directly adding members to the server specific groups) would fall back into using global permissions anyway.

/lp check, /lp user permission checkinherits etc. would follow the correct path and say they should have the correct permissions for that server (in this example worldedit.wand = false), but in game it seemed to follow a different path and they were actually getting different permissions (worldedit.wand = true).

commented

To expand on my setup, basically all global user groups have a "group.vanilla server=vanilla" permission, with all that servers permissions set inside the vanilla group with "server=vanilla" context explicitly specified.
Likewise any global staff related groups has a "group.vanilla_staff server=vanilla" permission.

Seemed a good way of keeping things separated and merging multiple ranks into just 2 for the much simpler and more restrictive "vanilla" server. After kick starting it by adding a user directly to the vanilla group, then removing them again it all works quite well.

commented

Alright, thanks for the additional details. I'll need to look into this one a bit more when I get a chance.

commented

I can't reproduce this using a basic test:

A fresh install of LP, configured as follows:

server: survival
include-global: false
include-global-world: true
apply-global-groups: true
apply-global-world-groups: true

Then:

/lp group default permission set minecraft.command.ban true

check result: false

/lp creategroup test
/lp group test permission set minecraft.command.ban true
/lp user Luck parent add test

check result: false

/lp group test permission set minecraft.command.ban true server=survival

check result: true

/lp group test permission unset minecraft.command.ban server=survival

check result: false

/lp user Luck parent add test server=survival

check result: false


The/lp check command seems to match up with that too.

Perhaps I have just interpreted your explanation incorrectly - but from my testing it seems that the system is working as intended.

Please could you provide a clear reproducible example of the problem in the same style as I have done above.