-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Permissions for(role) #1421
Permissions for(role) #1421
Conversation
iirc there is no typedef for RoleResolvable. There are also other instances (GuildMember role stuff) where the resolveRole method could be used for consistency. maybe that doesn't fit with this pr... |
260b09e
to
5b2ca32
Compare
a shitload of code is duplicated in those the if/else can you reuse some code plz ❤️ |
Perhaps I am missing what you are seeing? But I see no code that can be reused... Given the way permissions must be applied to resolve correctly that is. |
I think there is always an everyone overwrite and assuming that's true, one way to do it is the following:
This might be a little shorter but maybe a little more inefficient. |
That is specifically what you cannot do. Permissions must be applied in a specific manner according to https://support.discordapp.com/hc/en-us/articles/206141927-How-is-the-permission-hierarchy-structured- That was how permissionsFor was coded before an earlier pr of mine, and it caused incorrect permission resolution in several edge cases. |
Please describe the changes this PR makes and why it should be merged:
Allows role resolveables to be passed to permissionsFor() to check the resolved permissions for a given role after channel overwrites. (also adds a resolveRole method to the client data resolver, and cleans up a second instance where duplicate code existed)
Semantic versioning classification: