A revamp to permission hierarchy
This help article describes the current way in which permissions for a user are calculated.
The help article mentions that permissions are resolved using a hierarchy. However, the ordering of roles does not actually affect what is and what isn't allowed.
I believe this wording and method of permission resolving is confusing and prone to errors.
A simple example
Imagine I'm running a large support server for people who suffer from a chronic disease. In this server there are many public channels, but also some channels that should only be accessible to people who actually suffer from (and have to deal with) this disease.
The way we have this setup is by denying [at]everyone read permissions in the channel and explicitly allowing it for users who have a special role.
There are also channels where not everyone who can see it can type in it. This is set up by allowing read permission to certain roles, and then allowing write to only some of those.
Unfortunately, not everyone follows the community rules and we need to moderate them. Usually we believe that a simple mute is plenty. We rarely kick or ban users because the server forms such a valuable source of information.
Due to the current way Discord handles permissions, we cannot easily do this since allow permissions are always applied over deny permissions, even when the role that denies access is ranked above the one that grants it. this is a problem
Why does it work this way?
Discord has a very simple way of figuring out who is allowed to do what, and where. Basically it boils down to the following: first we figure out what someone isn't allowed to do, and remove those permissions. But then we look at what they are allowed to do (a green check mark in role settings) and suddenly the earlier setting that forbids something is erased.
My proposed solution
Instead of grouping all allows and denies before applying them, stack all the roles a user has and then look at them from the top. This way, the permission of the highest ranked role apply.
example
There are three roles: everyone, member, and muted.
We have a channel that should be invisible to everyone except for members. Muted users should not be allowed to talk in it (but still be able to see it if they also have the member role).
To set this up, we first configure the channel to deny read permissions from everyone. Then we allow reading and writing to members, and deny writing to muted.
Stacking the three roles, with everyone at the bottom and muted at the top, results in exactly what we want.
I believe that changing the permission system in this way does not negatively affect the way permissions are understood. In fact, I believe that actually making the system hierarchical like the interface and help articles say it is helps in making it easier to understand.
-
> Instead of grouping all allows and denies before applying them, stack all the roles a user has and then look at them from the top. This way, the permission of the highest ranked role apply.
This will solve neutrals, but how about disallows at the higher levelled role groups? You will definitely need an ability to determine to allow roles with equal power hierarchy levels, but with different actual powers in the scheme you suggest (using numeric modifers to determine the hierarchical ordering, to enable hierarchically equal roles). With that change applied, the permission calculation changes to:
- Sort all the roles of the user who is the member of according to power level of said roles.
- For each numerical power level (a collection of roles), lowest to highest, apply permissions. AND denies, then OR allows (allow wins for a given level, but still gets overruled by a deny in the higher power level). If you revoke a permission as a result of this computation as an owner, that operation will get irreversibly disallowed from you, unless you have someone else to "grant" again (explained below) — usual permission drop semantics.
- New "ban anyone", "unban anyone", "mute anyone", "deaf anyone", "undeaf anyone" permissions. When any of these permissions gets applied, it will overrule usual mute/deaf/ban/kick permissions.
- Separation of "manage roles" into "manage any permission", "grant permissions", "delegate permissions", "revoke others permissions". With this change, revocation of a permission from self will always be allowed per power drop semantics.
-2 -
Permission Hierarchies used to be a thing. That article just has not been updated yet.
However I do feel like they direly need to bring Hierarchies back. At least as an option. I have managed Servers, even if fairly small ones, for a few years now (roughly 2-3 years), and the roles used to be really easy to get to work. You could just add a new role on top, adjust its permissions and not have to worry about any roles below that. That was especially useful for muting people, since you could just put a "muted" role at the top and take away all talking permissions.
Doing this is now near impossible. Setting this up without a hierarchy is a huge hassle, having to juggle around with lots of roles. Truly this was a change for the worse, and I really hope they work on a fix asap, so I can actually fix my Server again. This change made it pretty much impossible to properly manage a Server without spending weekends juggling roles around, or setting up bots to do it for you.1 -
Well, fortunately, there is no such thing as equal hierarchy levels, Erkin Alp. Roles can either be above or below each other in your server settings, not next to each other. Same applies for per-category and per-channel. Additionally, as an owner, you literally cannot revoke permissions from yourself unless you transfer ownership.
1 -
Why fortunately?
> Additionally, as an owner, you literally cannot revoke permissions from yourself unless you transfer ownership.
You currently cannot. You will be able to, if this gets accepted.
-1 -
No, I see nothing about being able to revoke permissions from yourself as an owner, and I highly doubt the Discord team would implement that even if it were in there. Good morning.
1 -
I believe there needs to be a (group of) user(s) with absolute power if simply for the fact that it would prevent lockout. I don't believe that it's relevant for this feature request though.
0 -
Cas Lock-out is better than governance clash. You can start over or fork the community if you experience a lock-out. Which is what the Discord support team suggests when the community managers and moderators have disagreement among themselves anyway.
0
Zaloguj się, aby dodać komentarz.
Komentarze
Komentarze: 7