Allow slash commands to be used when Send Message is Disabled #5097
-
|
Currently when a user has the Send Message perm disabled and Use Application Commands enabled slash commands can't be used. Allowing application command use in channels where you can't send messages can be helpful for a variety of reasons, including:
|
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 10 replies
-
|
Adding to the list:
Having these permissions coupled is not very intuitive |
Beta Was this translation helpful? Give feedback.
-
|
While I totally see this use-case, I'm concerned about the potential impact on server permissions. Many server owners restrict send message permissions in channels that provide information or logging to their members. It would be very bad for users to be able to send slash commands in these channels, since non-ephemeral replies would disrupt the channel; interaction responses do not have permissions checks like this since the user expects a reply. While it would be possible for us to only enable ephemeral replies in this scenario, I am skeptical about the utility of this functionality. Furthermore, bots either start receiving errors that non-ephemeral replies are not allowed (which is not currently a failure case and would be a significant breaking change) or their responses are coerced to be ephemeral (which would be unexpected and probably unhelpful). What specifically are you suggesting here? As I interpret it, I don't believe this suggestion can be implemented. |
Beta Was this translation helpful? Give feedback.
-
|
In the case of existing channels, I only see this as a problem if the server currently has Send Message off, but Use Application Commands on for some reason. The solution from Discord's end is to turn off Use Application Commands perms for any channel in this state when rolling out the update. I agree that restricting replies to ephemeral isn't the solution but I don't think there needs to be a solution like this. I think if users want to turn off Send Messages for a user but still allow them to interact with bots, that's their choice. If we don't want bots sending non-ephemeral messages when Send Messages is off for a user, why can bot interactions still be used? A simple example is a verification gate. Users can still interact with bot buttons in channels they don't have Send perms to but they can't use context menus or slash commands. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @appellation, this could cause catastrophic confusion. I think discord could come up with a channel type called "Command Channel" or something. The channel does not have a chat but a list of commands from each bot. A layout similar to the forum channel home page. You can also type a command manually on a textbox at the bottom of the screen. Because there is not chat, users will not be able to see any command typed by others. I would love to see this on Discord and think it would drastically improve slash commands as a whole. |
Beta Was this translation helpful? Give feedback.
-
|
is it still happening? We can't repro in our client now |
Beta Was this translation helpful? Give feedback.
-
|
Did you actually do, or even try to do checks about this? Literally nothing was changed about this, even on Canary client. |
Beta Was this translation helpful? Give feedback.
-
|
Please review the Code of Conduct and refrain from addressing other people like this. |
Beta Was this translation helpful? Give feedback.
-
|
Oh sorry I think we tested the wrong scenario >< |
Beta Was this translation helpful? Give feedback.
-
|
The behavior of requiring ReasoningIt was decided that it didn't make sense to grant users with no ability to create messages in a channel the ability to create them via a bot. The thinking here is that the avenue for abuse is easy to accidentally setup when considering how By default, most people work with permissions at the role level and then setup sparing channel overrides as needed, so the main case here would be that While we could technically make the permissions separate (and thus also require channel-specific What about message components?Originally I called this a gray area because there is another type of interaction that can bypass We decided to maintain the ability to interact with these buttons given how the community was using them, often as a way to take action or interact without allowing messages to be sent in a channel, like with self-role-assigning bots. It was also decided that if someone with access to Possible solutions given the current system
You could have a separate channels to kick things off compared to the channel holding the LFG posts
In fact, I'd actually expect a setup like
You then can do one of two things
Honestly, theres nothing stopping you from still having an ephemeral command that gathers information and sends it to the admins. Not sure why this needs to be in a specific channel honestly. If you're deadset on it (maybe you want to have a
There is no real solution to this one in the current system. It is a workflow that we recognize some people might desire but given how the permissions behaviors would have to change to support it compared the the functionality that would be achieved, we don't feel this is a compelling usecase.
Not being able to use context menus does kinda suck, not gonna lie. This is a known problem (hello translation bots?) but given the things mentioned before, this isn't something we're looking to support currently. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed response. While my opinion is that it's still confusing, I understand the decision making process now and this isn't a critical issue. |
Beta Was this translation helpful? Give feedback.
-
Maybe you could separate context menus into a new permission, "Use Application Menus" or something, which would be separate from "Send Messages" whilst keeping "Use Application Commands" with the same behavior. This could also clear up some confusion as context menus aren't really commands per say. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the thorough reply. It has been a little while since I initially made the post and a lot of the new message components (along with ephemeral replies) cover a lot of what I was looking for (here's looking at you, modals!)
That's a bummer, but understandable. I do like IllagerCaptain's idea, though, and if context menu commands ever get expanded in the future it might be a good thing to consider. |
Beta Was this translation helpful? Give feedback.
-
|
@DV8FromTheWorld Has the team considered a potential solution like @vicenterendo mentioned here? Create a channel type that's essentially "bot/commands/applications-only" which would allow using these features but wouldn't send a message to a channel. |
Beta Was this translation helpful? Give feedback.
-
|
When are you gonna fix this?? We don't want ppl to be able to spam adult links in our welcome channel like they usually do. but we want them to be able to use a command. like wtf please fix asap. |
Beta Was this translation helpful? Give feedback.
The behavior of requiring
SEND_MESSAGESas well asUSE_APPLICATION_COMMANDSto be able to use commands (slash, context, etc) is an intentional choice that arose from having to make a decision in a gray area.Reasoning
It was decided that it didn't make sense to grant users with no ability to create messages in a channel the ability to create them via a bot. The thinking here is that the avenue for abuse is easy to accidentally setup when considering how
SEND_MESSAGESis used: When the permission is denied, a moderator can confidently assume that it means that a user will have no ability to send messages to the channel. This is typically critically important for something like announcement…