discord-api-docs
discord-api-docs copied to clipboard
discord
Updating an interaction always works like a classic webhook
Description
Permission calculation for webhook and interaction responses is available, but when updating an interaction, it hasn't been updated, there is still the old permission calculation system
Steps to Reproduce
create an interaction with a component that update during the update you will see that the emotes are not displayed anymore because everyone has no permission to send external emotes yet the bot can
Expected Behavior
have the same behavior as when I send an interaction
Current Behavior
there is not the same calculation system between an interaction and when updating the interaction
Screenshots/Videos
Before Update:
After Interaction Update:
Client and System Information
"discord.js": "^14.0.1",
Canary 138282 (cf09f46) Host 0.0.285 OS X 10.15.7 (21.4.0)
+1 This should be considered critical
I have the same issue and it's just killing my dice roller bot (see mentioned issue above) that now we are forced to use Slash commands (it was not a problem with prefixed commands and editing message contents).
+1 This should be considered critical
I have the same issue and it's just killing my dice roller bot (see mentioned issue above) that now we are forced to use Slash commands (it was not a problem with prefixed commands and editing message contents).
I agree, I have this issue many places in my bot. I have also seen it in large bots such as dyno and giveaway bot recently.
+1 This should be considered critical
I have the same issue and it's just killing my dice roller bot (see mentioned issue above) that now we are forced to use Slash commands (it was not a problem with prefixed commands and editing message contents).
you can send your message with interaction.channel.send this action send your message like "normal message" and you can get message for update after
+1 This should be considered critical I have the same issue and it's just killing my dice roller bot (see mentioned issue above) that now we are forced to use Slash commands (it was not a problem with prefixed commands and editing message contents).
you can send your message with interaction.channel.send this action send your message like "normal message" and you can get message for update after
In my situation, I would like to edit the original message. I can delete the original and send a new one.. but it can be confusing for the players, and it does not seem to work with ephemeral messages.
Hello ! 👋 (@appellation)
I just tested using the Edit Original Interaction Response route and it still doesn't work properly at the moment. It's still relying on the @everyone role when it should be relying on the bot permissions.
I don't have any problem when I try to edit a followup message.
Let me bring up the problem because I think there has been an update of the API since last week. Thank you !
It seems like this fix didn't resolve all of the scenarios in which this issue was occurring :( Currently looking into a complete resolution.
I also seem to experience this issue with my bot. Ephemeral interaction replies don't show emojis that the bot does not have access to, but does show custom emojis in the current server. Using a select menu with using the emoji option does show all custom emojis regardless if the bot has access to it or not.
It's quite confusing on how interaction replies and follow-ups don't show this and yet, select menu components do. These are both interactions so shouldn't this be following the same functions for how emojis are shown?
Giving the bot External Emoji perms does not work so this is frustrating.
I use discord.js v14.6.0. Unsure if this has to do with discord itself or discord.js
Even though example pictures were posted in the original issue, these pictures are showing how the emojis work in a select menu and not in the reply.
I also seem to experience this issue with my bot. Ephemeral interaction replies don't show emojis that the bot does not have access to, but does show custom emojis in the current server. Using a select menu with using the emoji option does show all custom emojis regardless if the bot has access to it or not.
It's quite confusing on how interaction replies and follow-ups don't show this and yet, select menu components do. These are both interactions so shouldn't this be following the same functions for ...
i think the reasoning is that interaction replies are webhooks (which are supposed to inherit the bot's perms now) while select menus are just general ui elements
Here are also two examples of how weird this is:
The one above is without @everyone having the rights to use external emoji
This one when @everyone has the right to use external emoji
The most weird thing about it (especially from the point of view of bot users) is that the buttons do show the icons, while the message doesn't (the two at the top are generic emojis). The message is created using the interaction.followup command and edited with the interaction.update command when using the buttons. I also did notice that were I to do a message.edit command on the message itself, the emojis would show up. But having actually retrieve the message with every interaction and then editing it is not very straightforward as the message id has to be saved and retrieved from the database object behind the post, then the message has to be retrieved and then edited. And that wouldn't fix the first time the post is created using the interaction.followup (or interaction.reply) statements.
Hello, I would like to bring up this issue that dates back several months ago and is still not fixed to this day.
I am a developer of a multipurpose bot that has more than 350k+ guilds and we have game commands such as power 4 or tic-tac-toe where we use external emojis from emoji servers that we own and use to enhance the presentation of our messages.
If a server that uses our game controls and has not allowed the @everyone role to use external emojis, it really ruins the game experience. Here is an example with the power 4 without this permission on the @everyone role.
Some servers, especially servers with a certain number of members, make the choice not to allow all their members to send external emojis to avoid some outbursts, which is pretty normal. However, we cannot currently provide the experience we want to provide to our users without compromising their server moderation with incorrect emojis.
We also have some specific utility commands as well as some generic confirmation messages to our bot that are impacted by this issue.
I know the problem can be worked around right now by editing the message instead of interacting, but it impacts our performance, as we have to send any message and then edit it with the correct content. Not to mention the fact that these requests, which are no longer interaction requests, are not immune to a global ratelimit.
I really hope we finally get a response from Discord for this problem and that it is fixed soon. This issue has been around for several months now and this bug is problematic for bots like ours that use external emojis to enhance the user experience.
It’s been 5 months and this annoying bug is still not fixed. Please, just tell us anything already.
Can confirm that this is still present, for me it is whenever you defer a message, making it send "Bot is thinking", then proceed with a followup that has a custom emoji in it. Made sure bot has access to the emoji, it works without the defer and no followup.
Pretty much noticed this right after I rewrote my entire bot to use interactions instead of message commands :(
Why can user made webhooks allow any emoji to be sent but not bot owned webhooks?
Note, that user webhooks and the bot owned webhooks both have external emoji permissions
Why can user made webhooks allow any emoji to be sent but not bot owned webhooks?
Note, that user webhooks and the bot owned webhooks both have external emoji permissions
Bot owned webhooks can only use emojis the bot itself has access to User owned ones doesn't have this restriction
You just responded with what they just said. They were asking why that restriction exists.
it's a side effect of bot webhooks using the bot's permissions. if the bot can't access the emoji then its webhooks can't either because they share the same permissions
iirc they originally said the change wouldn't impact emojis, then it did and they refused to change it
it's a side effect of bot webhooks using the bot's permissions. if the bot can't access the emoji then its webhooks can't either because they share the same permissions
iirc they originally said the change wouldn't impact emojis, then it did and they refused to change it
it would be nice if discord commented on this.
No, it isn’t. It’s a side effect of bot webhooks using @everyone permissions. Obviously if the bot had permissions as many in this thread have pointed out theirs do, they wouldn’t be reporting it as an issue. They are. I am. Bot webhooks need to use the bots calculated permissions. Fix it by next year please.
On Sun, Feb 19, 2023 at 05:15 Suspense @.***> wrote:
it's a side effect of bot webhooks using the bot's permissions. if the bot can't access the emoji then its webhooks can't either because they share the same permissions
iirc they originally said the change wouldn't impact emojis, then it did and they refused to change it
— Reply to this email directly, view it on GitHub https://github.com/discord/discord-api-docs/issues/5279#issuecomment-1435960322, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGKKCZJ3OSSL7YPPQ2ED4DWYH6FTANCNFSM55TNWLEQ . You are receiving this because you commented.Message ID: @.***>
