Suppose I have a track that looks like the following:

default -> donator1 -> donator2 -> donator3

With the way I set up perms (following Microsoft best practice), groups represent roles, and as such, those groups only have as many permissions as is required to fulfill that role and nothing more. This means, the default group, which acts as my member role, will only have those permissions required by the entire playerbase regardless of staff membership, donation, and so forth.

An administrator in this model may have admin, mod, donator2, and default. This would give them server administration permissions, user administration permissions, the appropriate donation perks, and the base user permissions.

If my track is set up like the example above and I were to run the command /lp user Foxtrek_64 promote donator, the end result would be that I am removed from the default role and placed into donator1. This means that I've just lost all of my user permissions!

One solution to this is to have all of my donator groups inherit from the user group. Another would be to have all of them inherit from each other in reverse order to the track (3 inherits from 2 inherits from 1...).

However, I would like to suggest a different solution to this, being something that would be configured (though I admit not having any ideas as to how).

Option 1: Sticky default
If a track begins with default and the user is promoted along the track, default should be considered a permanent group and the net result would be the person having default and donator1. Further promotions would see the player has donator1 and replace it with donator2, then donatorN. The strength of this system is that it allows multiple tracks to begin with the default group and as such if you promote along one track they're not instantly ineligible for being promoted along another.

This is particularly useful for situations where you have multiple tracks. Both of the those paths can just call the promote command respective to the appropriate track without having to worry about preventing the user from being promoted along the other track. I suppose it would be possible (with most services) to just run two commands - promote and then manually add back the default group, but this would be susceptible to race conditions.

Option 2: Additive mode
When a user is promoted along a track, instead of the senior rank replacing the subordinate rank, the user would simply be added to the senior rank. If following the ladder above, a person promoted up to donator2 would have the following ranks (assuming no others are applicable): default, donator1, donator2. This could arguably be replaced by using /lp user <user> parent add <group>, however for situations where you require a generic command (such as a command to run on donation), you may not always be able to deduct which group the user should be added to, and thus the generic nature of the promote command adds a large amount of utility.

Anyone who has a moment, I would like to see your thoughts on this suggestion! Point out any additional modes that may be beneficial, situations I had not considered, or work-arounds I missed. Sometimes the easiest solution is just to change how I do things.

That said, while groups being members of other groups is possible, I would like to find a solution that avoids that. In situations where there are a large amount of groups, it can get very complicated very quickly as to what groups inherit from what.

your perm groups should inherit the previous group as needed. this means any promotion along that line will maintain previous perm groups.

your perm groups should inherit the previous group as needed. this means any promotion along that line will maintain previous perm groups.

That's a very good point, @ktole1999. And that matches the recommended configuration. The issue is if you want to automatically promote without them manually being added to the lowest group of the track, then one needs to make the lowest group of the track the default group. This works well, as long as there is only one track - users will be promoted to the next lowest rank in that track, that rank replacing default.

But if you have multiple tracks, such as a donator track and a staff track, that all have default as their lowest tier, then as soon as a user is promoted along one track, they become ineligible to be promoted along another by virtue of not being on that track any longer.

There are two solutions to this problem: promote and then manually add the user back to the default group, though this is susceptible to race conditions, or remove the default group and manually add the user to the lowest tier of the track manually.

Both solutions have their share of problems. As mentioned above, the first is susceptible to race conditions, but it is the only solution of the two that work with online donation portals. The second solution is not available for online donation portals, meaning they are unable to rely on the promotion feature entirely and must manually add the user to the group they donated for. However, this second method is adequate for a staff track or other similar track where manual promotion will be used anyways.

I’d like to point out that if you promote someone on a track that they are not on, they get the lowest group in the track added to them.

I really think this would have been far better suited to be discussed on the Discord.
In general it’s best to talk about suggestions in a Discord if available.

I agree Discord may be a better place to have a discussion.

My server has three tracks, one for graylisting, one for staff, and one for donors. The setup that works for me is:

Track    | Path
---------+----------------------------
Greylist | default -> greylist
Staff    | chatmod -> mod -> admin
Donor    | donor

And I have both chatmod and donor inheirt the greylist group, and it works well for me.

I'm happy with the current track functionality, unfortunately it's not possible to extend it any further without making the commands really complicated - at least I can't think of a way.

I'm going to close this suggestion on the basis that it's unlikely to make it into the main plugin in the near future. A quality PR implementing this functionality would likely still be accepted, but it's not something I'm going to work on. :)