Open Luc1412 opened 7 months ago
Hey! Just a few questions to better understand this:
I see the frontend has a couple bugs reported here where it's letting you try to run commands that will fail due to permission checks, and changing channels is losing the reason for it failing, but I want to double check if there was a recent backend breakage in here too.
context menu commands are supposed to not work without Send Messages, except user-installed commands, which are forced ephemeral. They worked for guild-installed commands for a short while (few weeks?) but this was considered a security issue, as it could create public messages in read-only channels, and was blocked in the backend last week as a bug fix.
Is the application you're using installed to the server or to your users?
This is a good old classic server app.
Was this working in your server before and broke, or is this more of a feature request?
I think I never tested it myself, however another dev that contributed to the bot told me it was working fine.
as it could create public messages in read-only channels
As long the context menu is ephemeral only, it should be fine too. This could also be forced, instead of letting it fail with an error message,
As many of you have mentioned this is is a feature request to force guild apps responses to be ephemeral. I've updated the issue to reflect that. This is something we've actually decided against doing because it would be considered a breaking change.
We could potentially look at other ways of doing this in the future so I'm going to leave this open as a feature request.
My server has a custom context menu command to report messages to staff members of the server, just today members were confused why they couldn't report messages in our #welcome channel.
I would appreciate some sort of change that would allow ephemeral responses to be possible, as it's confusing that the app command is available to be used there, but doesn't work and just errors out.
As many of you have mentioned this is is a feature request to force guild apps responses to be ephemeral. I've updated the issue to reflect that. This is something we've actually decided against doing because it would be considered a breaking change.
We could potentially look at other ways of doing this in the future so I'm going to leave this open as a feature request.
The inherent usage here is we want to allow individuals to run ephemeral context menu commands in read-only channels.
For example, an individual wants to implement a context menu command that allows a user to translate a message and have it ephemerally given back to the user in the same channel. Hope to see this problem solved in the future!
This works for user-installed commands now, but it is intentionally disabled for guild-installed commands.
Is there any update on this? Because i wanted a bot that translates messages with an ephemeral message, but it's impossible in read-only channels, it would be very useful for us as we all speak different languages.
+1 on this, even if via an explicit parameter in the response that you are okay with a fallback to ephemeral, it would be a really great feature, especially in things like locked threads.
Description
It seems like since the backend support for user commands had been added, context menus doesn't work if the user got no send messages permission.
I think these commands should at least work, when the response is ephemeral.
In our case we got a feedback system, where users fill modals with there feedback and webhooks post it, so the users itself got no write perms. However they should be able to report feedback trough context menus, which doesn't work now.
Steps to Reproduce
Expected Behavior
The command will be normally (ephemerally) executed
Current Behavior
The command can be used, however an "Missing Permission" error appears:
Also after switching the channel and going bac, the messages changes from "Missing Permissions" to "The application did not respond":
Screenshots/Videos
No response
Client and System Information
ptb 279006 (1671f3f) Host 1.0.1062 x64 (45361) Windows 11 64-bit (10.0.22631)