Support channel ranks in permissions

[gdude2002]

It's been a long time coming, and this may be somewhat related to #73, but it's finally time to tackle this. I've got an idea how I want to do this, but I'm going to need some feedback. @rakiru?

• I think the best way would be to define special groups that align with the channel ranks. For the sake of customizability, higher ranks wouldn't automatically inherit lower ranked-groups - but that could be set up manually, as you currently can.
• I feel like these groups should be part of the command handler stuff - process_input could take an argument containing any extra groups to apply to the user, and that could be used during the permissions check
• As an example, I might say that irc-@ could be the group for channel ops on IRC. I'm not sure how Mumble works - comments?

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/22368529-support-channel-ranks-in-permissions?utm_campaign=plugin&utm_content=tracker%2F269930&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F269930&utm_medium=issues&utm_source=github).

[rakiru]

• Special groups of some sort definitely seem the way to go. It takes the existing system and builds on it, instead of trying to add something entirely new. We may want to reserve some specific prefix for all "special" groups such as this, and any others in future. I agree that manual inheritance would be best.
• I'm not entirely sure what you mean by this. Do you mean that these special groups should be passed into the permission check function rather than be tied to User objects somehow like the others? I'll have to think about this in more detail, but ideally they wouldn't be too different from regular groups.
• Other than the prefix suggestion above, this sounds good. Mumble could be done with a group per ACL or something. One concern I have with IRC is that different networks have different prefix characters, but I'm not sure if there's any real way we can abstract that away anyway.

[gdude2002]

For your second point..

• I didn't want to put extra groups into the User object as I feel that should be more about global state for the user than something as transient as this - it would also avoid race conditions with people doing stupid things with threads
• Prefixes aren't the same but we keep track of that anyway, right? If we're doing this dynamically, then it should be fine.

Also, how would we reserve special group names? I mean, what would reserving do? I can't think of an appropriate restriction honestly

[rakiru]

• In what way is this more transient than regular groups? User objects are controlled/maintained by a specific Protocol object, which are the same things that deal with changing channel ranks. I'm not necessarily suggesting that we store them directly in User objects, just that they are mapped to them somewhere in a way that is transparent to the user. The command handler isn't the only thing that does permission checks. As for threads, we don't support threads in pretty much any of the API and it's blind luck if something works across threads. I don't think this should be a concern.
• We keep track of them yeah, but only +o and +v are standard (iirc), so the rest are mapped against arbitrary modes and relative power.

How? Put a line in the docs saying "groups beginning with foo are reserved and should only be used for the intended purpose". Why? So people don't name a regular group irc-@ and get confused when Ultros does something weird with it. Perhaps a . or _ would be sensible?

[gdude2002]

Alright, I decided to come back and look at this again, and I feel like it would probably not be all that hard to get this implemented into the permissions system as it is.

However, we should finalize a few things.

• The prefix - rank-<groupname>? group-<groupname>? Something else?
• Tracking - I suggest having a function in the User object that can get the specific rank a user has for a channel, which would work fine for our purposes here and be much more useful on a general scale.

[rakiru]

Prefix for what? How would this tie in with the existing system?

[gdude2002]

The prefix for the relevant permissions group.

The previous discussion seemed to decide that adding per-protocol permissions groups for sets of network-rank-related permissions was the way to go, so we need to decide what the key should be structured like.

[gdude2002]

Upon review, this kinda looks really backwards.

What else can we do? Separate ranks section?

[gdude2002]

I've added get_extra_groups(self, user, target=None) to the base protocol. As permissions should be pretty much self-contained, I feel like this is the best way to go as it still allows people to write their own permissions handlers if they want.

While the above layout does look pretty weird, I can't think of a way of fixing it without breaking the current permissions data files at the moment, so I'm going to press on with it for now. We can always change it later if we think of something better.

[rakiru]

Use cases:

• Give @ (and above) across all channels on all networks basic channel management commands (e.g. kick, ban, etc.)
• Give + (and above) in all channels on specific net restricted commands (e.g. domainr, drink, loud-mode commands)
• Give @ (and above) in specific channel on specific net some channel-specific commands (e.g. project-specific plugin command)

Does what you've added work for all of these?

Additional use cases:

• Give opers network management commands (we don't currently track oper state)

[gdude2002]

It should work fine for those, but it doesn't automatically do rank inheritance - is that something we want?

[rakiru]

Explicit inheritance is probably fine, although it'd need to be made clear in the docs.

I just noticed, you're only returning the highest rank of the user in the IRC protocol. What's the point of main it return a list, then only returning one item? It should probably return a list of groups in order of importance.

The IRC protocol should then return all groups the user is in. Although, I guess, since the way IRC works, each group supersedes the previous, it might make more sense to either only return the top group, or return all groups under it too. Hmm...

[gdude2002]

On IRC, groups are mode-based (obviously). While the only prefix shown in most clients is the highest one, technically users have only the groups in their modes. For example, on Stormbit, being a channel owner with ChanServ gives you +qo, which is irc-~ and irc-@ respectively.

I feel like we should just go with the modes and hand them all to the permissions system at this point.