Slash Command Permissions

[maanex]

Description

Allow slash commands to be only executed when a user has specific permissions in the channel they're using the command in. These permissions can be set individually for each slash command, allowing moderator only slash commands for instance.

Why This is Needed

While it is possible to check permissions after a user has sent a command and reply with a "you don't have the permission to execute this command" type of text, having unusable commands hidden in the ui entirely would resolve in both, a better user experience, and less server side (bot, not discord) code.

Example use cases where this would be useful:

• a /warn command that kicks users with 3 warnings should only be executable by users with the "kick members" permission
• a /bulkdelete command to delete multiple messages at once should only be executable by users with the "manage messages" permission

Alternatives Considered

Alternative would be to manually check the permissions on each slash command execution. This works currently but has two major downsides:

• the command is still visible in the user interface and auto-completes without letting the user know they can't use the command
• extra server side code for permission checks is required (and possibly even having a bot in the same guild)

Additional Details

Taking the example JSON object from the documentation, a simple "permission" attribute with a bitfield as the minimum required permissions would be how I imagine to set these permission requirements:

json = {
    "name": "blep",
    "description": "Send a random adorable animal photo",
    "permission": 0b10000000000110, // Permission bits as seen everywhere else in the app. The user would have to have all of those permissions in order to use the command.
    "options": [
        {
            "name": "animal",
            "description": "The type of animal",
            "type": 3,
            "required": true,
            "choices": [
                {
                    "name": "Dog",
                    "value": "animal_dog"
                }
            ]
        },
    ]
}

Additional/custom permission checks (like having a specific role) would still need manual permission checks and "no permission" responses.

[iSaluki]

I feel that something like this would be a necessary feature for slash commands to properly get used by the community. At the very least, I'd expect to be able to create moderator or admin only commands, but being able to bind commands to individual permission(s) would be a much fuller solution.

[msciotti]

We will support a permission system for Slash Commands. After talking to developers and some community folks, it seems like being able to set permissions on roles/users is more beneficial for end-users than defining specific permissions on commands. For example, two roles in your server may both have Manage Message, but you only want one of them to be able to use a /delete command.

Our current thinking is:

• We will support "overrides" for commands, like we do in channels
• Overrides are valid for guild and global commands
• Overrides will be valid for a user or a role
• If you do not have permission to use a command, we will remove it from your command explorer list (when you type /)
• You can effectively disable a certain command within a guild by denying @everyone the permission to use that command

This approach does not solve the case for some developers--"I only want people with Manage Server to see this command"--but creating it like our existing permission overrides is more in line with how servers define their permission structure, and has the added benefit of allowing "Only this user can use an admin command in the bot".

[muddyfish]

This approach does not solve the case for some developers--"I only want people with Manage Server to see this command"--but creating it like our existing permission overrides is more in line with how servers define their permission structure, and has the added benefit of allowing "Only this user can use an admin command in the bot".

Will we be able to define 'sensible defaults' for commands? Say we have a 'nuke entire server' command, it would be pretty bad if anyone could use it. The same is true for less extreme examples such as a 'upload emoji' command

[MinnDevelopment]

So you expect users to setup the permissions for every command of a bot? What if the bot adds a new ban command and all servers now have that command available to all users in the server?

[SinisterRectus]

If you do not have permission to use a command...

Will these overrides use a whitelist/allowlist or blacklist/denylist mechanism?

In other words, what is the default behavior if no overrides are set?

[advaith1]

Personally, I think it's weird to not support setting it by Discord permissions; I assume most bots' checks are by Discord permissions (for example, checking Kick Members for a /kick command). While user/role overrides would be useful, it doesn't fix the main issue imo.

[somebody1234]

one thing to consider is that unless you heavily nest commands, in any moderation focused server the moderation commands will take up way more (screen) space than the non-moderation ones, making it extremely difficult to find a usable command for the vast majority of users. of course, this isn't an issue with most bots, however quite a lot of general purpose bots do exist, and i believe it'd be a blocker for them to switch to slash commands.

re: not supporting setting it by discord permissions, i think that's a complete non-issue since you're supposed to use roles to manage groups of permissions in the first place; shifting the permissions from the user to the bot would simply be, well, a shift in paradigm

[MrStooby]

I just discovered this implementation of bot commands via slash and it is very interesting but in the case of my bot, it bases some user commands on a level system and the levels are identifiable within Discord by roles. Likewise my moderation commands are linked to a role rather than a permission. According to me (and because it suits me ^^"), it would be to link the command with one or more roles (either the id of the role, or by the name)

[KAJdev]

While I can understand that roles are meant to group permissions, I can't think of any friendly/scalable way to link specific commands with specific roles or users for every guild a bot is in. Being able to link commands to specific permission ints would be way more useful and intuitive. It also isn't a bad idea to consider supporting both. For example, supporting specific permission filters for global commands as a default, while having server moderators being able to manually override those like roles.

[somebody1234]

I really, really think linking commands to permissions is way too restrictive. Note that it'd fall upon the server owners/moderators to manage the roles that are allowed to use certain commands, and unless you have 100 moderation roles or 100 moderation commands, it won't take long (more than, say, 5 minutes) to set up the commands for every role from scratch. As for how you'd do it, it could be a button or another section in the permissions tab (?) for each role

[MrStooby]

As somebody1234 says, the best solution will be the roles. When I looked for bots for my server before making mine, many bots were based on the name of a role, a room or a user etc... and very few were on a permission. Basically, it was the rule of : If you install my bot, you abide by my naming requirements.

When it comes to customizable commands with an administration interface to manage them, the problem is less because the id of a role is reusable when the command is created.

I think, there are several implementation techniques and the api devs should take this into account by integrating the "permission" parameter as suggested in this thread but also integrate a "roles" parameter which would be an array of IDs or names to be as flexible as possible.

[KAJdev]

When I looked for bots for my server before making mine, many bots were based on the name of a role, a room or a user etc... and very few were on a permission. Basically, it was the rule of : If you install my bot, you abide by my naming requirements.

I have never come across a bot like this in all of my years in discord. Every moderation/multi-purpose bot I can think of goes off of permissions.

[somebody1234]

Note that moderation bots go off of permissions because there is currently no interface in Discord. I strongly believe that setting slash commands by role is the objectively correct way to go, since they are pretty much just custom permissions.

[advaith1]

sounds like you guys might not be aware that there is already support for setting command permissions by user/role: #2737

however imo setting permissions by Discord permissions is much more user friendly and needed, I'm not sure if I'll integrate the current permission system or how that would look like, but I'd definitely use permission-based permissions (currently I just check permissions in the code like for message-based commands)

[somebody1234]

Note that you can simulate setting permissions by Discord permissions by adding a role for each permission. You cannot do the converse (simulating setting permissions by role if you can only set permissions based on Discord permissions).

Again, as I've said above it should not take much time at all to enable commands based on roles, no? The only issue is with older servers with a lot of roles, and even then you only need to do it once (the single time being now, when slash commands have just been added), meaning a couple of months at most this should be a complete non-issue.

[Nihlus]

Surely it doesn't need to be one or the other? Both approaches have their valid uses - roles and user overrides are more flexible, but discord permissions are more generic and easy to use. Conversely, role and user overrides are difficult - if not impossible - to implement at a global scope, and discord permissions may be too limited (or too broad).

The best of both worlds (and something that would be incredibly useful for future interaction types) would be a way to define and use our own custom permissions on a guild and global level, the same way we define slash commands today. It solves both issues - it's flexible like user and role overrides (since you could use them like normal Discord permissions), and easy to define once and use everywhere.

Simply using role and user overrides for everything is a hack. It works, and isn't a bad solution per se, but it's certainly not the best way to do it in the general case.

[somebody1234]

That's like saying using roles to grant permissions is a hack...

[muddyfish]

Simulating Discord permissions does not work in the general case; only 10 overrides are allowed at most. Also, keeping this in sync whenever you start up would take tens of thousands of requests even for relatively modestly sized bots. Introducing a single new command would require millions of requests, which even at a higher global rate limit would still take hours.

Allowing a developer to specify a set of permissions which can use a role would provide a good set of defaults that prevent permissions escapes, significantly reducing the time to set up a new bot as you don't need to understand the fine detail of what every command is capable of

[somebody1234]

Keeping this in sync

I do not believe this is needed whatsoever; the idea here is that the responsibility falls on the server owners, therefore you would make exactly zero requests to keep this in sync (since the bot would then not manage permissions whatsoever)

EDIT: Note also that you would also be able to specify a set of permissions and handle permissions for slash commands on guild create and role create/update events.

EDIT 2: To clarify, AFAICT the list of commands should be the only thing you need to sync (if this is an incorrect assumption please let me know); if you don't have guild commands at all that's one request. If you do have individual commands for each guild, ideally you'd only be editing commands when the bot is online anyway - otherwise scaling to more than a few guilds will be a nightmare.

[AnotherCat]

I think that slash command permissions should be as open and flexible (for developers) as possible. A few things I would like to see Permissions based on user permissions

An option for permissions for all guilds for that command, ideally in the command object when registering the command. This would support both user permissions and user ids User ids because there might be some commands you want to enable for certain users regardless of guild. eg dev only commands

A bulk permissions endpoint for each command which supported creating, getting and patching. This would solve the issue of ensuring command permissions are in sync, and updating on mass. Also a way to remove specific overrides in each guild with a single patch request to this endpoint, possibly removing the override when it's the same value as default_permission, why I think is needed is because say I had 1000 guilds with permissions, but only wanted to delete a one permission override from each of 100 guilds, with the current system that would mean 100-200 requests. Most of the time when a bot is added to a guild, or settings changed singular endpoints would be used, but changes are made to bots all the time and implementing changes could be massive.

Being able to maintain a role / user based permission set will be really important for a lot of bots, a lot of bots extend what discord can do and discord permissions sometime just don't make sense for those features.

Another thing that would be great is the ability to create groups of commands, which are then enabled / disabled by server administrators directly on roles / channel overrides. This wouldn't replace being able to set commands per role / user / permission, instead ideally a layered system where the developer has control, but which allows more granular control on a server level is the developer wants that.

Sorry if I've repeated things others have said, this is just what i think would be great to have :smile:

[maanex]

Okay I think it's important to differentiate between public and private Discord bots in this conversation. For private bots is makes sense to have commands tied to roles or users since the bot owner can easily modify those on demand. This is already possible as mentioned by advaith1. For public bots this is not really practical. There is a reason global slash commands exist and maintaining guild slash commands for every guild is just unreasonable and should not be the standard way to manage permissions.

So what I think would be the best solution for both worlds is have each slash command tied to a discord permission but allow Discord server admins to override command access on a per role / per user basis, individually for each command.

Keeping it in the middle would only allow the command if the user has the command's pre-defined permissions. Alternatively admins can grant or revoke access individually. This would have the benefit of the granular control people requested but would also allow for scalability for larger bots as well as default configurations which are 100% needed (imagine a /ban command being accessible for everyone because the server admin didn't update the permissions yet, or vice versa people not being able to use the most basic commands because the server admin forgot to allow it after adding the bot).

The conversation unfortunately got lost in repetitive argumentation over the same 2-3 arguments, so please keep any followups short and to the point, thanks.

[somebody1234]

For public bots this is not really practical.

I still strongly believe this is not true. As I have said multiple times, this is because it would be the server owner's/mods' responsibility, not the bot owner's, to select the roles that can use certain commands.

imagine a /ban command being accessible for everyone because the server admin didn't update the permissions yet

This can be solved by adding a single configuration setting - whether to have the command enabled by default.

EDIT: To put it in other words (again?), all moderation roles required someone to go through and enable each individual permission in the first place, it should not be much more effort to configure the additional permissions that a moderation bot would add.

[maanex]

all moderation roles required someone to go through and enable each individual permission in the first place

Yes, that's usually the case. But don't forget that many inexperienced Discord users get started using server templates and don't actually set this up themselves. Now picture those people adding a bot, would you really think they would figure out why they can't access a command?

it should not be much more effort to configure the additional permissions that a moderation bot would add.

This entirely depends on how many commands the bot adds. But even if it's just one command I don't see why it should be required to always go into the settings and change the permissions if you can just have a default value.

Your solution might work, but it certainly doesn't deliver the best user experience.

[AnotherCat]

An in app way of admins controlling commands is great, however i think that it could very easily become confusing / hard to navigate. (Worst case scenario 500 commands iirc). A parameter for allowing a command to be controlled by admins, and permission grouping would help with that, it should also allow devs to completely disable commands (meaning server admins can't enable them and see them).

For public bots this is not really practical.

I disagree, depending on rate limits, this would only really entail updating permissions each time settings are updated for that server, which isn't unreasonable. Problems do exist if there's an update to commands, a bulk endpoint would help with that. Another reason for groups, permission overrides could be assigned to a group and commands are assigned to those groups, messing updating could mean not touching permissions.

Overall there are many different ways and ideas about how people have previously implemented permissions. I think that ideally most of what's been suggested here should be implemented, because it's not really up to us to decide what's good and will work for everyone. After all one of the major things about slash commands is server side validation, which i consider this included in, and if people still have to do their own validation because permissions based on permissions doesn't exist, that's really not great. (Sorry about this being so long, it is as short as I could make it)

[somebody1234]

TL;DR my point: I feel like for the vast majority of cases, the commands you're offering will not have a 1:1 correspondence with existing Discord permissions; at most the bot should enable certain commands based on permissions when it first joins.

Now picture those people adding a bot, would you really think they would figure out why they can't access a command?

Trivially solved by sending the admins/mods a message on join; a large number of bots have on-join messages (for every user) already so I don't think this will be too much of a problem. Furthermore (and more importantly, especially if you focus on ease-of-use) if the bot requests appropriate permissions, they can potentially (read: should be allowed to. Whether or not they currently can, I don't know) set those up themselves in the first place.

This entirely depends on how many commands the bot adds.

Valid point, but note that adding a moderation role already requires granting between, say, 4 and 15 permissions depending on the level. Note also that especially on small servers, you generally won't have more than say, an owner, admin, and three levels of moderator roles. At a generous estimate of 100 commands (which would be very bad user experience, I'd imagine - you're probably better off using subcommand groups) that'd take... surely not that long. An alternative, as AnotherCat mentioned, is having command groups

Note also that all of this only really applies to moderation bots as far as I can see; for the vast majority of bots this would just not be applicable. (To check this, go to any management bot's dashboard and see if any non-moderation non-config commands are restricted by permissions)

[Nihlus]

Leaving the previous ideas aside for a moment, I'd like to expand a bit on what I mean by custom permissions now that I'm at a proper keyboard.

Generally speaking, the goal of this feature request is to allow creators of slash commands to efficiently hide, block, or otherwise make unavailable certain commands from certain subsets of users - a typical permission functionality. What I believe would be the best way of solving this in the general case is the introduction of distinct, user-creatable permissions for use with all manner of interactions - not just slash commands.

Similar to how Discord permissions are used today, these custom permissions could be used by bots in much the same way.

Spitballing here, this would be my take on an API surface that these permissions could be managed with, and how they might be used.

Permissions

A new set of API endpoints and structures are introduced to represent permissions.

Application Permission

Field	Type	Description
id	snowflake	the ID of the permission
application_id	snowflake	unique id of the parent application
guild_id?	snowflake	the ID of the guild the permission belongs to
name	string	the user-visible name of the permission
description	string	the user-visible description of the permission
default?	Default Permission Choice	the default state of the permission. Defaults to allow.

Default Permission Choice

Name	Value
Allow	0
Deny	1

Create Global Application Permission

POST /applications/{application.id}/permissions => 201 Application Permission Creates a new global permission. Comparable to Create Global Application Command, this permission is available in every server the bot is a part of, and most likely takes a while to propagate due to Discord's synchronization methods.

JSON Params

Field	Type	Description
name	string	the user-visible name of the permission
description	string	the user-visible description of the permission
default?	Default Permission Choice	the default state of the permission.

Get Global Application Permission

GET /applications/{application.id}/permissions/{permission.id} => 200 Application Permission Retrieves a global permission by its ID.

Edit Global Application Permission

PATCH /applications/{application.id}/permissions/{permission.id} => 200 Application Permission Edits an existing global permission, updating one or more properties on it.

JSON Params

Field	Type	Description
name?	string	the new user-visible name of the permission
description?	string	the new user-visible description of the permission
default?	Default Permission Choice	the new default state of the permission.

Delete Global Application Permission

DELETE /applications/{application.id}/permissions/{permission.id} => 204 No Content Deletes an existing global permission. Returns 403 Forbidden if the permission is still in use by an interaction, in order to prevent accidental privilege escalation.

Create Guild Application Permission

POST /applications/{application.id}/guilds/{guild.id}/permissions => 201 Application Permission Creates a new guild permission. Comparable to Create Guild Application Command, this permission is available in a single server, and updates instantly.

Field	Type	Description
name	string	the user-visible name of the permission
description	string	the user-visible description of the permission
default?	Default Permission Choice	the default state of the permission.

Get Guild Application Permission

GET /applications/{application.id}/guilds/{guild.id}/permissions/{permission.id} => 200 Application Permission Retrieves a guild permission by its ID.

Edit Guild Application Permission

PATCH /applications/{application.id}/guilds/{guild.id}/permissions/{permission.id} => 200 Application Permission Edits an existing global permission, updating one or more properties on it.

JSON Params

Field	Type	Description
name?	string	the new user-visible name of the permission
description?	string	the new user-visible description of the permission
default?	Default Permission Choice	the new default state of the permission.

Delete Guild Application Permission

DELETE /applications/{application.id}/guilds/{guild.id}/permissions/{permission.id} => 204 No Content Deletes an existing global permission. Returns 403 Forbidden if the permission is still in use by an interaction, in order to prevent accidental privilege escalation.

Slash Commands

The slash command API is amended with the following changes.

Create Global Application Command

POST /applications/{application.id}/commands => 201 ApplicationCommand

JSON Params

Field	Type	Description
name	string	1-32 character name matching ^[\w-]{1,32}$
description	string	1-100 character description
options?	array of ApplicationCommandOption	the parameters for the command
permission?	snowflake	the custom permission required to use this command. If no permission is set, anyone can execute the command.

Edit Global Application Command

PATCH /applications/{application.id}/commands/{command.id} => 200 ApplicationCommand

JSON Params

Field	Type	Description
name?	string	1-32 character name matching ^[\w-]{1,32}$
description?	string	1-100 character description
options?	array of ApplicationCommandOption?	the parameters for the command
permission?	snowflake?	the custom permission required to use this command. If no permission is set, anyone can execute the command.

Create Guild Application Command

POST /applications/{application.id}/guilds/{guild.id}/commands => 201 ApplicationCommand

JSON Params

Field	Type	Description
name	string	1-32 character name matching ^[\w-]{1,32}$
description	string	1-100 character description
options?	array of ApplicationCommandOption	the parameters for the command
permission?	snowflake	the custom permission required to use this command. If no permission is set, anyone can execute the command.

Edit Guild Application Command

PATCH /applications/{application.id}/guilds/{guild.id}/commands/{command.id} => 200 ApplicationCommand

JSON Params

Field	Type	Description
name?	string	1-32 character name matching ^[\w-]{1,32}$
description?	string	1-100 character description
options?	array of ApplicationCommandOption?	the parameters for the command
permission?	snowflake?	the custom permission required to use this command. If no permission is set, anyone can execute the command.

Data Models and Types

ApplicationCommand

Field	Type	Description
id	snowflake	unique id of the command
application_id	snowflake	unique id of the parent application
name	string	1-32 character name matching ^[\w-]{1,32}$
description	string	1-100 character description
options?	array of ApplicationCommandOption?	the parameters for the command
permission?	snowflake	the custom permission required to use this command. If no permission is set, anyone can execute the command.

Usage

Now, how would these permissions be used? The image @Maanex posted above does a great job of picturing it (save for the fact that it's not on a command-by-command basis, but rather a true permission, like the ones that ship with Discord today).

When editing a role's permissions, or an override for a role or user, the available permissions from the bots in the server would be available for configuration and could be selected just like any other permission. Allow, deny, or inherit - just the way we're used to.

In terms of slash commands, each individual command could optionally declare that it needs the invoking user to have a specific custom permission. If the user doesn't have the permission, the command is hidden from view (or sorted into its own category of unavailable commands). Since we're integrating with the existing permission infrastructure, roles and overrides are also considered. For future interaction types (buttons, anyone?) the same system could also be used, graying out/making unavailable various interactive elements based on the user's custom permissions.

Why?

The reason I'm yammering on about this is because bots encompass a lot of topics. There's music bots, roleplaying bots, sports bots, homework bots, moderation bots, you name it. All of these bots need some way of restricting their commands to subsets of users, and it's only in very few cases those needs map to Discord's built-in permissions in a sane way. This has led most bots to roll their own permission systems, for better or for worse.

Allowing application creators to define their own well-integrated permissions would make things a whole hell of a lot easier, both for the developers and the end users - no more fiddling with different permission commands, or trying to match up Discord's permissions with the bot's needs. It's the same reason why we have slash commands now - nobody wants to sit around guessing what to type in, or fiddling with permission mappings that don't make sense. Instead, there could simply be a "Issue Warnings" permission under the moderation bot's category, or a "Create Character" permission under the roleplaying bot's.

Of course, one could use the tools we have to day - roles - and treat each individual role as a unique permission (or smaller groups of permissions), but that would quickly balloon out of control, not to mention that each bot would need its own implementation and handling of it. I'm not saying it's not doable - I'm just trying to look for a better way.

Unsolved Issues

This is just something I typed up after some short thinking on the subject, and I'm sure there are many flaws and holes in it. Here are some of my own thoughts I've not decided one way or another on - food for thought!

• [ ] How do builtin Discord permissions fit into this? What if a command or interaction wants to use "Manage Nicknames", for example?
• [ ] Should permissions be able to depend on the user also having a builtin Discord permission? If so, how?
• [ ] What about requiring multiple permissions for a single command? Should applicationcommand.permission be an array instead, perhaps?
• [ ] How should custom permissions be integrated into the role and overwrite structures? Bitfields, like the existing Discord permission sets? What about when there's permissions from multiple bots? How do custom permissions map to individual bits, if this is how it's done?

Hopefully, this will spark some conversation and some new ideas on the subject :) I'd hate to see a half-baked quickfix solution get implemented when there's so much more that could be solved with a proper, more extensive implementation.

[somebody1234]

Since nobody else has said anything yet, I might as well, I guess (re: the unresolved issues)

How do builtin Discord permissions fit into this?

I think it'd be fine given that this would move visibility completely to permissions rather than individual slash commands. (As others have mentioned, this is especially useful for moderation commands, especially the ones that 1:1 correspond to Discord permissions, e.g. ban/kick-related commands.)

Should permissions be able to depend on the user also having a builtin Discord permission? If so, how?

I think having defaults (= set only on creation) would work fine, i.e. when the bot is added or a permission is added/edited, its custom global permissions are set for each role/user if they have the corresponding Discord permission. (Of course, there are a number of issues with this such as figuring out whether to remove said permission on an edit given that the permission may have been manually given)

What about requiring multiple permissions for a single command?

It sounds vaguely useful, however I'm not sure if making .permission an array for (potentially) relatively few commands is a good idea... it'd probably be good to have some examples to better figure out how useful it is.

How should custom permissions be integrated?

Bitfields for each individual bot might work (note that this should be fine since commands themselves are already grouped by bot), however note that even then there'd be a couple problems to iron out, e.g. when global permissions are added/removed. If the bitfield format needs to be synced every time the bot starts that would probably be an issue as well.

If you have just a list of snowflakes for permissions rather than a bitfield, a bunch of these problems would go away, but then there's the potential problem of requests to update permissions being very large. Not sure if that'd be a problem or not. Alternatively, if bitfields are only used for permission updates that might work too (fetch list of permissions where list[0] = first bit -> send patch request with appropriate bits set or something).

As for overwrite structures... zero clue what you mean there so if you could explain that'd be great

[VerdeQuar]

What if someone is an admin on a server and doesn't want to see slash commands? (cause autocomplete is messed up) Permissions are ignored for admins so this wouldn't work. Maybe a switch in client settings to disable autocomplete and slash commands UI?

[msciotti]

Just doing some housekeeping as I cross-reference open issues.

This issue is tied to this PR: https://github.com/discord/discord-api-docs/pull/2737

Will close this issue once that PR gets merged (which is just me slacking, sorry).

There's a lot of discussion here, but I think the crux of it has actually been brought out by others. Tying commands to roles and users is more in line with how people run servers, and is generally more flexible than tying to Discord permissions. Creating in-client UI to do that assignment is a project that's top of mind (cheers @Nihlus for the cool mocks).

[Nihlus]

@msciotti Thanks, though the credit for the UI mockup goes to @Maanex :)

I feel I should point out that simply adding a way to tie individual slash commands to roles and users with overrides won't be enough for the majority's use case (although useful in its own right). One should not preclude the other, and being able to define our own permissions for our bots would be incredibly useful.

I don't think this issue should be closed once that PR is merged, since the proposed solutions in these discussions are wider than the scope of those changes. If it must be closed, then at the very least the proposal for custom permissions to group our commands (and future interactions!) with should survive in some fashion.

[advaith1]

I think merlinfuchs' proposal which rxdn posted in https://github.com/discord/discord-api-docs/pull/2737#issuecomment-808521557 would be the best solution:

default_permission should take a permission bitmask integer, not true or false. This would allow for commands to be restricted to users with certain permissions, without having to add all users and roles individually for each guild.

that way it still keeps the flexibility and possibility for overrides set by server admins, but also allows tying to Discord permissions which many bots already do, and is much simpler.

[maanex]

I absolutely agree with @advaith1 here, a simple boolean value is simply not enough to use the full potential of slash commands. Whether it be Nihlus' proposal to handling permissions or simply allowing a bitfield as the default_permission, I don't mind, but the current solution is more limiting than it has to be.

This issue / feature request was not about allowing commands tied to individual roles or users, this issue was specifically directed at slash commands being regulated by discords already existing permission system. The changes in #2737 are great and a step in the right direction but have nothing to do with this issue in particular. Closing it now would be the wrong decision in my opinion.

[msciotti]

I understand the original intent of the feature request, yes! What I'm saying is, at this time, we do not have plans to allow assigning discord-specific permissions to individual commands.

The solution that we have now shipped is the system we believe in moving forward.

That's not to say we will never allow discord permissions to operate this way, but it is not currently planned. Though it is noted, so I can promise we won't forget about it.

[edwardshturman]

Just stumbled upon this; for anyone still struggling with it:

Sorry to say, team, but I agree — I really don't see why you shouldn't let bot devs make this choice for themselves. I can't say it's good UX for server mods, either.

Right now, I'm using this as a workaround:

const { Discord, Permissions } = require('discord.js');

if (!interaction.member.permissions.has(Permissions.FLAGS.MANAGE_MESSAGES)) {
    await interaction.reply({content: 'Sorry, you don\'t have permissions to do this!', ephemeral: true});
    return;
}

[advaith1]

this GitHub issue is old and support for tying a command to Discord permissions is being added in command permissions v2, which will go into private beta this month

also, discord.js is just one of many third-party libraries for the API

[edwardshturman]

Sure, but SlashCommandBuilder (what I'm using) doesn't have anything the official API doesn't; the application command permissions structure is the same. 🤷‍♂️ This looks nice! Looking forward to the new default_permission changes. 👍

[bouncingmolar]

Server Permission: View slash commands

This is necessary and simple.

How it works:

It is a permission toggle when applied to a bot allows or prevents it from displaying or responding in the slash command menu. This allows control over which channel or bot role makes each bot's slash commands accessible.

Simple because:

It uses the permission system consistent with the existing ones (eg view message history) which everyone will be familiar with already.

Necessary because:

prior to slash commands bots were able to be constrained to channels within servers: music bots to music. games. fun. moderation. Now that all bots are implementing /commands its unwieldy to show all bots in one menu and degrades the user experience.

permissions for each command.

Discussion in previous comments about servers individually assigning permissions to each command is not consistent with how discord works and this should be left to the bot developers and bot configuration dashboards. Bot developers should be able to hide commands from roles/users/permission level.

[maanex]

An update on the situation as not everyone seems to be aware of this. Discord is currently building a slash commands permission UI (and API for that matter) which looks something like this:

This is not exactly what this issue was proposing but it does serve the same purpose. The screenshot above is still a beta or even alpha version of the UI so things might change but so far there haven't been any major roadblocks I am aware of so I hope to see this shipped to everyone soon.

[bouncingmolar]

wow. that seems over the top. but welcome never the less.

[soshimee]

Any predictions to when this will be implemented?

[i0bs]

Any predictions to when this will be implemented?

I predict 2070 when we all move to neuralink and talk to one another via the brain waves

[TwilightZebby]

Any predictions to when this will be implemented?

For a more serious response, there is no ETA other than "before the end of April", since that's when Message Content Intent will be enforced after all.

[soshimee]

I mean, Discord should give time for developers to migrate, and with such an essential feature lacking many will find it hard.

[AlmostSuspense]

That's why the deadline was postponed

[KevinNovak]

Will this be added to mobile at some point?

I run a couple decent sized bots and want to switch over to slash command perms for the benefit that guilds have complete control... but the lack of mobile support for command permissions is kind of a deal-breaker. If I rely solely on command perms I can just imagine questions from all the mobile users who don't have that option.

[bouncingmolar]

I've been testing the new slash command control in the integrations area. A couple of observations.

All bots are still listed even when there are no permitted commands available. Ideally bots with no permitted commands should not be listed in the slash command menus.

Not all slash command bots are listed in the integration area... At least on my server.

[AlmostSuspense]

You don't need slash commands to be listed there, the integrations tab shows other information unrelated to slash commands like granted permission or who added it and when. You also can only see the first 50 integrations added to the server

[bouncingmolar]

Aha thanks!! I do have exactly 50 listed so that's correct(and a pain)

I also meant that for users whos permissions are removed, they can still see the bot listed in the command menu even though there are no available Commands to them. The bot should just be absent. (I wasn't sure if I made sense the first time)

[bouncingmolar]

Will the 50 limit stay? That seems a bit deficient. I mean imagine you could only apply permissions to the first 50 people in a server.

I think I'll go back to my original suggestion which is to have a toggle in the normal role based permission area.

An easy way would be to reuse the application command permission That permission is useless for bots currently because bots can't use slash Commands anyway.

Instead it should toggle whether commands for this bot are visible or not in a channel.

No control over individual commands of course but better than the no control at all with the 50 integration limit. Also no reason to remove the integration way too. Would be nice to be able to choose which bots are listed though.

[AlmostSuspense]

iirc they don't plan on modifying the limit