Restrict slash command visibility by role, user, or permissions

[MeguminSama]

Description

Currently, slash commands are automatically visible to any user sharing a server with the interactions. My proposal is to add the ability to lock the visibility of commands (in the commands list) down to an array of role IDs or user IDs.

Why This is Needed

Currently, if you have role-specific commands (e.g. /ban, /kick, /mute) every user can see these. Ideally, we would be able to display these commands only to the users who are able to run them.

Alternatives Considered

IDs can be checked server-side to lock a role down, however it is still visible in the commands list to users who shouldn't be able to use them.

Additional Details

This could be implemented by adding a roles and users array to the ApplicationCommand object.

An example:

{
    "name": "blep",
    "description": "Send a random adorable animal photo",
    "roles": ["1234", "5678"],
    "users": ["1234", "5678"],
    "options": [...]
}

Edit: 19/12/2020

Perhaps we could also get a "permissions" key which would define the minimum required permissions to see a command.

For example, the following restricts the command visibility to users with either: BAN_MEMBERS permissions, OR roles with ID 1234 or 5678, OR users with ID 1234 or 5678

{
    "name": "ban",
    "description": "pull out the ban hammer",
    "roles": ["1234", "5678"],
    "users": ["1234", "5678"],
    "permissions": 4,
    "options": [...]
}

[ImpossibleReality]

This is definitely needed as a feature. Maybe also add a permission argument to lock command to users with certain server permissions (like those with only manage message for mod commands)

[MeguminSama]

Maybe also add a permission argument to lock command to users with certain server permissions (like those with only manage message for mod commands)

I was just about to suggest this ^

[petitchou]

I cannot overstate how useful this would be. I would love to move my moderation commands over to something like this, but I'd really rather not have all the moderation commands just hanging out in the menu for regular users, you know?

This should be labeled as a feature request, though. I don't know if this is mistagged or not, looking at everything else. Ignore this, please. ❤️

[macdja38]

I like the idea of this but worry it won't be complete enough to be useful. For example my permissions system allows restricting a command to one channel or a role / user in a channel.

[MeguminSama]

I like the idea of this but worry it won't be complete enough to be useful. For example my permissions system allows restricting a command to one channel or a role / user in a channel.

This has been somewhat requested in https://github.com/discord/discord-api-docs/issues/2342

[MatkoGH]

This is really needed. Cluttering the commands list with commands that people can't even use is a pretty bad user experience.

Maybe add some sort of categories that we can sort the commands into in the future as well?

[Burkino]

Slash commands could have their own per guild settings. Just like like roles have guild wide and channel specific options, slash commands could be the same. If a bot has a mute command the owner could enable a mod role access to that command but deny it to other roles. And if the bot has an 8ball command the owner can enable it in a bot commands channel but disable it in a general channel.

[zikeji]

Slash commands could have their own per guild settings. Just like like roles have guild wide and channel specific options, slash commands could be the same. If a bot has a mute command the owner could enable a mod role access to that command but deny it to other roles. And if the bot has an 8ball command the owner can enable it in a bot commands channel but disable it in a general channel.

This would be ideal, but it's a big ask IMO. A simpler approach like OP (with a few tweaks) would be quicker to implement and allow bot creators much more control.

I think the quicker solution in the short term would be adding a permissions bit option for global and guild level commands, and then a roles & channels option for guild level commands. While users would be nice, I imagine the overhead on the clientside wouldn't be ideal, and if it were added would have to be limited to a maximum amount.

Additionally, for it to allow bot creators maximum flexibility, and to reduce load, we don't want bots to have to only create guild level commands for global commands just to get roles/permissions support (although this approach still could work). A more optimal solution is to add guild level permission, roles, and / or users overrides to a global command. And to add into this, a global default invisible on global level commands would be nice (as opposed to limiting their permissions to say, server owner, then overriding when the owner configures them).

So basically ApplicationCommand would get a permissions, roles, and users option in the schema / data model, but adding roles/users to a global command would result in a 400 error. And then for the overrides there would be a new model, e.g. ApplicationCommandOverrides and a new endpoint.

Multiple approaches could work.

1

In this approach we don't add a new ID for overrides, and simply associate a global command ID and a guild ID.

GET/POST/PUT/DELETE /applications/{application.id}/guilds/{guild.id}/commands/{command.id}/overrides

or

GET/POST/PUT/DELETE /applications/{application.id}/commands/{command.id}/guilds/{guild.id}/overrides

Personally I think the latter is the most inline with the current endpoints. You can't create multiple overrides for the same command in a single guild, but this shouldn't be necessary when you can simply update the override. And PUT may not be necessary in either because POST could do the same thing, just overwrite it.

2

In this approach overrides get their own unique IDs as well. This means you could create multiple overrides per command in a guild, however this doesn't seem beneficial aside from making some implementations easier.

GET/POST /applications/{application.id}/commands/{command.id}/guilds/{guild.id}/overrides PUT/DELETE /applications/{application.id}/commands/{command.id}/guilds/{guild.id}/overrides/{override.id}

or

GET/POST /applications/{application.id}/guilds/{guild.id}/commands/overrides PUT/DELETE /applications/{application.id}/guilds/{guild.id}/commands/overrides/{override.id}

In either case I think the above approach would be a great one, and server admin UX feature for slash commands can be a low priority. This would give slash commands a similar level of functionality as current text based commands in terms of what bot developers can do. Since most larger bots will already have command level permissions, migrating to slash commands wouldn't require too many changes to logic and still allow the bot dev to provide maximum flexibility to the server owners.

[msciotti]

I'm going to de-dupe this into this: https://github.com/discord/discord-api-docs/issues/2315

Restricting visibility will inherently come with restricted usability.

[iNgeon]

Would really like to see this, at the moment in Integrations > Command Permissions as it says "restrict usage of this applications command to roles and channels" but would appreciate if slash commands worked with the existing channel permissions that if a bot is restricted from View Channel\Read\Send Messages that blocking the use of slash commands would not even show the user that bot in the slash list just like that bot would not appear in say a text channel in between the users when it is restricted. Also avoids confusion for users when certain bots are restricted to certain channels for easy of usability (like Music bots in music only channels etc)

[vitu0089]

This would be awesome, I look forward to the day where I don't have to explain certain commands responding with "Access Denied"

[zikeji]

You've necro'd an old issue that has already been resolved.

Permissions for individual slash commands (as well as defaults for a specific bot) are managed by server owners under Server Settings -> Integrations -> Bots and Apps.

You can set the default_member_permissions to 0 to restrict a slash command to admins only, letting server admins determine who can use that command (basically in cases you want a default off command).

If you're using a library to interface with Discord's API, you would want to consult it's documentation for the best approach.

[JoshClark431335]

the point is not about being able to use the command, but rather to even view the command when typing slash /. Read OP.

[AlmostSuspense]

this is already how it works, if you don't have permission to use a command it won't be visible to you

[nosferatus96]

Anybody know if there has been any temporary remedy to this bug? Not having a method to control the visibility of these slash commands can become problematic when there are many, it becomes difficult for users to sort through them. To re-iterate, it isn't about controlling the right to execute a slash command but rather simply preventing users from another channel to see a specific slash command within a guild.

[advaith1]

There is no bug reported here. In Server Settings > Integrations, you can select allowed channels for any application or command, and the commands will not be visible in other channels.

[nosferatus96]

Again, as far as I can tell this has nothing to do with the visibility.

If you take time to read the Integrations Panel in Server Settings: "Restrict usage of this application's commands to roles, users, and channels.

Usage is one thing I've already got covered, visibility is another...

[advaith1]

If the command is not usable then it is not visible. Discord does not show commands to users who do not have permission to use them.

[advaith1]

I have read it. This GitHub issue was made in 2020, when slash commands were new, long before the current command permsision system existed. Back then it was not possible to control the roles/channels that can see each slash command, but now it is.

You could try it for yourself, or read the support article:

If someone in my server doesn’t have permission to use a command, will they still see it in the command picker when they type “/”?

No, commands will be hidden from members who don’t have permission to use them.

[zikeji]

The scenarios in the OP of over three years ago are already addressed. I'm not sure what you're after here, if I set a command to be only usable by a certain role, only a user with that role (or server admin perms) can see and use it.

The control bot developers get is basically limited to whether a command is default everyone or default admin only. The latter being useful for administrative commands, allowing the server owner to set permissions without having to worry about a brief window anyone could use the command.

While you can certainly manually restrict usage as a developer in your code itself as some sort of precautionary measure, managing usability in the integrations view of the server settings is how it's intended to be done. If it's not usable, it's not visible.

[MeguminSama]

This issue was resolved in a way that I and many others were happy with.

If you are looking for additional functionality, please open a new issue and provide constructive feedback.

[nosferatus96]

In the event that somebody in the future falls in the same scenario, I think it's impossible or at least very difficult to have the commands hidden from specific channels for you if you're the server owner, all along the solution was working just not for my account, sorry for wasting your time @advaith1

[zikeji]

In the event that somebody in the future falls in the same scenario, I think it's impossible or at least very difficult to have the commands hidden from specific channels for you if you're the server owner, all along the solution was working just not for my account, sorry for wasting your time @advaith1

Same applies to anyone with admin perms unfortunately. Under the roles portion of of the server settings you can "view server as role" and I use that to verify visibility quite often.