-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MANAGE_ROLES/MANAGE_PERMISSIONS does not implicitly grant MANAGE_MESSAGE #487
Comments
Please correct me if I'm misunderstanding, but you're saying that a person with Manage Roles can and needs to explicitly grant themselves Manage Messages in order to do so, so everyone with Manage Roles should just always have Manage Messages because they might grant it to themselves? I'm not sure I see the problem, as it's so much easier to check for explicit permissions granted in the permissions bits than it is to figure out implicit permissions. Furthermore, as a bot, if your library were to assume that just because you have Manage Roles that it has Manage Messages, that would lead to further errors, unless it were to do something like catch the exception and grant itself permission and retry (which, would be awful) And as it says:
There is no logical connection between managing roles (a server-level task) and managing messages. They have nothing to do with each other. Contrast this with say, View Channel - you obviously cannot manage messages in a channel you cannot view. |
Yes. A user with Manage Roles permissions can create a permission override for themselves or anyone else or any role, giving them Manage Messages (interestingly, they cannot create or edit a role granting Manage Messages).
That's not really the point. The point is that there appears to not be a clear documentation of whether Manage Messages should be implicit to Manage Roles, or not. There are other implicit permissions already.
That's exactly what's been happening for at least the past 6 months in the JDA lib.
I don't really care whether there is a logical connection or not (I think there is, but I'm fine with any decision by the developers, as long as they make an official one and follow through with it), I just want the lib and Discord to agree to treat this similarly. |
It would not be practical to provide an exhaustive list of all permission combinations to fully describe what permissions are implicit, and why that note about "logical use" is there. In any case, this is how the API currently behaves with Manage Messages not being implicitly granted with Manage Roles. It is easy to test this, you already know that this is how it works. That is clearly a bug with the library, and there's no point in waiting for Discord to change anything, if they will even do that. (it would take much less time to fix and simply revert later) |
I don't see why giving a user The fact that JDA assumes that This is just my opinion, please don't scream at me |
When I first reported this issue to @jhgg I was told it was going to be worked on. This is clearly an inconsistency on discord's end and I'm not willing to change our logic when this will change in the future. |
With that being said, due to the complexity of the permissions system I don't think I'd feel comfortable implicitly granting extra permissions with |
I think that the behavior of channel-specific But that means that it is in theory granting all permissions implicitly which is neither documented to not be the case nor is it taken into account in all the API endpoints that require some specific permission in that channel. So in my opinion, it should either be documented that it is not in fact giving implicit perms (like someone would assume) or changed all together to not give implicit permissions, which would be kinda bad as i really love the possibilities it currently opens. Would be nice to hear what exactly the plan from Discords side is (possibly final statement) so that it can be written into stone and coded against. As it is right now it is definitely not 100% clear what Discords intention with that permission is and that is the actual problem of this thread. |
The current work-around I see is granting yourself the permissions explicitly. def can_manage(channel, user):
if user.has(channel, Permission.MESSAGE_MANAGE):
return True
if user.has(channel, Permission.MANAGE_PERMISSIONS): # equivalent to ADMINISTRATOR in channel context
user.grant(channel, Permission.MESSAGE_MANAGE)
return True
return False I suggest one of either:
|
While the use case kantenkugel describes is perfectly reasonable and in fact an amazing feature i feel like i should point a slight irregularity in logical use out that i have not seen mentioned before. If you explicitly deny VIEW_CHANNEL for a bot you generally don't want it to interfere with this channel at all. The affected target is however able to set overwrites to the channel although "view" is explicitly denied (as long as it has MANAGE_ROLES in its final permissions - eg granted as base permission on the bot rolel), meaning it can effectively force access to a channel it's not supposed to be in. I have not seen that specific point covered here and feel like it fosters malicious intend. |
Honestly, implicit permissions just make things more of a hassle, because we don't know exactly what we're getting. |
Long time, no updates. I'm working towards a proper fix to this condition which will introduce the following breaking change to updating permission overwrites:
|
This is deployed. |
@night Correct me if I'm wrong, but the only role permission that currently allows you to override |
Owners/administrators at the guild level can assign a MANAGE_ROLES overwrite, and users who have a MANAGE_ROLES overwrite can also assign a MANAGE_ROLES overwrite within that channel. |
Hi,
the docs say
According my understanding a user that may manage roles/permissions, can end up giving themselves the permissions to manage messages, so that permission should be granted implicitly. However, in reality, it is not.
Informally, this was verified with a chat with Jake/binzy (sorry I don't remember who exactly it was anymore, and can't find it in DAPI anymore :^) ) that this is indeed the desired behavior. It has now been almost 6 months and the behavior has not been changed, so I'm opening the issue here, to make this a bit more formal. JDA already supports this behavior, which leads to 50013s unless a ton of explicit checks are done. They basically said they do not intend to change the behavior as long as there is no official stance that this implicit permission grant is wrong.
Please let us know what the plans are with regards to this issue, so this discrepancy can be resolved soon.
related issue: discord-jda/JDA#414
The text was updated successfully, but these errors were encountered: