LuckPerms

LuckPerms

41.4k Downloads

Ignore default group when doing track promotions/demotions

nelind3 opened this issue ยท 0 comments

commented

Description

When promoting a player along a track the action fails if the player is in more than one group that belongs to said track. However if you promote a player along a track that has the default group on it (which is reasonable to do for things like meta-formatting) the check does not ignore the default group which leads to the action failing.
If the command instead ignored the default group in its calculations the action would prove more useful for evolving servers.

Proposed Behaviour

Say theres a player in the groups default and donator and both default and donator are in the rank track for meta-formatting purposes. Then said player buys a rank up. Running /lp user player promote rank would then look at the groups the player is in, ignore the default group and remove the donator group and add fx. a donator+ group.

Extra Details

Id say it makes sense both for the default group to be completely ignored by both promotions and demotions (neither counting it when figuring out a players current progress along a track nor removing it when that progress is changed) or have the commands ignore the default group when figuring out the current progress and then removing it from the player once as part of the promotion/demotion in a sort of "clean up" action. Both make sense to me. Id say it mostly hinges on how you look at the purpose of the default group (as a baseline that everyone is part of or as a starting point that can be moved out of).

You could say that the player should just be removed from the default group before attempting promotion. However id argue that one: at least to me it makes sense to have the default group be applied to everyone all the time (though that is more of an idea of how the default group should be used that may not align with how its use was intended) and two: perms are an evolving system on most servers and since the default group get applied to everyone having it be handled as a special case by the track system makes sense not only for ease of use but also because the plugin simply knows more about the purpose of the default group than any other group and can make decisions based on that knowledge.