Problem:

When a user inherits parents / groups from default, it doesn't play nicely with the ladders.

Expected:
Given the following simplfied permissions
https://gist.github.com/ryantheleach/a8df02fcd6b163fc9c848c28028f7179

Players should start on the bottom rung of the ladder, when promoted along the ladder once, Skylom should be in the group PokeFan only, rather then Youngster + Pokefan.

Reality:

Users inherit parents rather then copy the defaults as a template. this makes it quite hard to use the default rank in a ladder in any meaningful way, except where further ranks along the ladder explicitly inherit from previous ranks. This locks people into a very very specific perms structure, and results in countless mistakes as you need to remember to deny permissions on each rank.

Fix:

In order to fix this, some way of copying default parents / permissions to a user rather then virtually inheriting them would fix this, but I can understand if this goes counter to the rest of the permissions structure.

Alternatively some way of marking a ladder to automatically grant users the base parent would also be a suitable workaround.

Workaround:
The clear workaround for this would be to deny any unwanted permissions that are inherited from youngster, this causes repetition + mistakes, but it works. alternately defining some sort of Anti-Youngster subject, with deny ranks with higher priority could also work.

IRC Transcript:

<ryantheleach> Hey guys, with the default ladders. It seems like it's impossible to have someone start at the base rank, and have it removed once they move up?
<ryantheleach> http://hastebin.com/jupigabala.json
<ryantheleach> given that pex file (not mine someone I'm helping)
<ryantheleach> subjects.default.user.parents = group:youngster right?
<ryantheleach> and on the default rank-ladder it's the first rank of the ladder
<ryantheleach> I get that's it's an inherent problem in the inheritance, but shouldn't the rank ladders have a way of starting on a specific rank?
<ryantheleach> and if so, how should that be acomplished?
<-- Tenebrae has quit (Quit: Be back later)
<ryantheleach> zml, not sure if you are around, but I'm guessing given the information provided it's a quick "it's possible this is how" or "this isn't possible yet, open a ticket"
<zml> yeah that's accurate you should open a ticket
<zml> maybe like a default ladder thing?
<ryantheleach> not sure, it's more like "copy parents to user" rather then inherit

It came to mind that default parents are hard to remove in general.

Ex: giving default ranks to people joining the server is a good thing, it saves time, but when banning someone, you may also wish to revoke all their default perms, and change them to a banned group, so should your banning system fail, or should you use a jail plugin instead, the user will be unable to cause harm.

So maybe some general way to "anti-inherit" permissions? I would suggest some way of inverting the permissions of a subject that is set as a parent, but that complicates things, also 99% of the time when you assign a permission as -1, it's because you are denying something to override bad inheritance structure, or as a safety net in case someone fails to assign perms correctly. converting those to +1 could be potentially disasterous, this is also a flaw in the way that bukkit permissions handled inversion IMO.

skylom {
  parents:[DENY(Youngster)] ? //All positive weights are turned to negative
  parents:[INVERT(Youngster)] ? // (weight) -> -weight
  removeDefaultParents:[Youngster] ?
  parents:["group:somethingThatInheritsYoungster", "-group:Youngster", "group:Pokefan"] (read as, remove Youngster from inherited default parents + somethingThatInheritsYoungster, ignores parents of Pokefan as it came after?)
}

Clearly the goal is to avoid explicitly copying the defaults into each user, so that updating the default subjects updates all users, as well as reducing file size for each logged in user with default perms, while keeping a sane structure.