Description

I have two tracks, a track of ranks, and a staff track.
The moderator group in the staff group gives permissions to some of worldedit.navigation, and different groups along the rank track provide increasing access to these permissions.

However, I want to prevent deny these permissions in certain contexts. These are provided by an external plugin that does region protection.
The problem is that at the moment, in order to deny all navigation permissions in a particular region, I have to go through each group along the rank track and also the moderator group and add a deny permission with a context of the region. This means updating 12 different groups with the exact same node. Just on different groups.
This seems to be because each time you add a new permission you are applying that ontop of existing permissions, meaning that the context can't deny that permissions as it comes from a sub-group.

Perhaps I am missing an exist feature here, and if thats the case please show me what to do, I have looked through the documentation and couldn't find any way to do this.

Proposed Behaviour

I would like to be able to set the denial node on a single group, for example on the default group or some inherited group.
As it stands at the moment I can't seperate out the context node onto another group and add it as a parent, as the group will take precendence over its parent, which means that it does nothing.
This seems like a difficult problem with how luckperms is structured, and the only ways I can think to be able to do this would be:

• A parent group that could be configured to take more precedence that the group underneath it (I have tried setting the parent's weight higher than the child's, this just seems to cause the child's weight to be upgraded to the parent's weight) or configured to take equal precedence (in which case the contexts would still work as contexts take precedence if theres a tie in this case).
• Some kind of alias/pointer for a node that provides a layer of indirection, so instead of typing out the whole node each time, you only need to specify that this group uses the node named "movement-region-restriction" and then this is applied as an actual permission member with the same precedence as a "concrete" node.

Another solution could be to setting a weight for an individual node, but I think this is against LuckPerm's permission style, as groups already have weights.

Extra Details

No response

Hi,
This seems like something that inheritance would solve.

For example if you have the groups admin, mod and helper on the staff track and make the helper group a parent to the mod group, then mod group would get all the permissions that the helper has.

You can just add a helper to mod as a parent with /lp group mod parent add helper then anything that helper has, mod will also get.

Thanks for your reply,
So our tree looks something like

wood (adds navigation.jump)
  |
iron (adds navigation.thru)
  |
gold (adds navigation.up)

(the mod thing is a bit irrelevant, that doesn't really act any differently in practice, its just in another track)

We want to deny the entire node navigation in a bunch of contexts, at every rank along the track

So if we added a parent group:

base (denys navigation in certain contexts)
  |
wood (adds navigation.jump) <- navigation.jump being set to true overrides the contextual deny since its inherited
  |
iron (adds navigation.thru) <- navigation.thrubeing set to true overrides the contextual deny since its inherited
  |
gold (adds navigation.up) <- navigation.up being set to true overrides the contextual deny since its inherited

The end result being at any level, nothing is denied.

So this doesn't solve our problem, and its something I tried. This behaviour does make some sense though as otherwise it would cause other unwanted behaviour, which is why I think a new feature would be needed.

When you're setting the permission to true, give it a context for where you want it to be true, that way the denied contexts from the base group still apply.

When you're setting the permission to true, give it a context for where you want it to be true, that way the denied contexts from the base group still apply.

This would still mean repeating myself, and more than originally, so this doesn't help.