'Managed Roles' on a Role should not apply itself to a higher Role the user has.
I actually reported this a bug, and was told it was a design feature.
Short description: More of a design flaw, a role with the 'Manage Roles' permission will apply itself to higher roles the user has as well.
Steps to reproduce: This is the first action to take - Make a server with 10 roles. This is the second action - Give the middle tier role the 'Manage Roles' permission. This is the third - Give a user that mid tier role, AND a role above that.
Expected result: The user should only be able to assign/edit/remove roles under the mid tier role.
Actual result: That user will be able to assign/edit/remove roles under the highest assigned role it has, NOT only under the mid tier role.
This shouldn't be how it works. I don't want all powerful Role changing gods, I want designated users to be able to manage a SPECIFIC group of roles under the 'Role Managing Role', even if it has a role above it on the Role list.
-
For those who want the higher roles to be able to 'Manage Roles', all they have to do is add that permission to the higher role.
0 -
I just ran into this, and I wholly agree with the OP. The "Manage Roles" permission should not set the role hierarchy access based on the highest role the person holds but the highest role that confers the permission.
I don't see a good reason for the current behavior. If we wanted higher roles to have that control, we could give it to them.
Use case: I have admin/mod stuff at the top, a bunch of cosmetics in the middle and a quarantine role at the bottom. I want to create a new helper role so that trusted members can put people into quarantine. But this won't work the way I want (even if the helper role is just above the quarantine role) because the helper with Manage Roles permission will get control over the highest cosmetic assigned to them instead of just the bottom role.
Manage Roles is much too powerful to delegate without the ability to better target what it can do, and using the role level where it's assigned would be an intuitive and useful improvement to that.
edit: A workaround for this use case is something like a YAGPDB custom command. The bot can be configured to enable a command for a role, and the command can be a single specific role. For example a custom command named "quarantine" would support "-quarantine user" and could be given to a specific role.
{{giveRoleName (userArg (index .CmdArgs 0)) "quarantine"}}
0
Accedi per aggiungere un commento.
Commenti
2 commenti