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.

[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 #2737 (comment) 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

[Shark-93]

I agree with @bouncingmolar on #2315 (comment) but, even though I could live with that on Desktop, I opened Issue #5427 because on mobile all bot slash commands are still suggested to you even though they're denied in the channel (by means of channel permissions in Server Settings Integration page).

edit: okay I thought my app's version was somewhat recent, I was wrong