-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slash Command Permissions #2315
Comments
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. |
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 Our current thinking is:
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 |
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? |
Will these overrides use a whitelist/allowlist or blacklist/denylist mechanism? In other words, what is the default behavior if no overrides are set? |
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. |
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. 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 |
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. |
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. |
I really, really think linking commands to permissions is way too restrictive. |
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. |
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. |
Note that moderation bots go off of permissions because there is currently no interface in Discord. |
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) |
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. |
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. |
@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. |
I think merlinfuchs' proposal which rxdn posted in #2737 (comment) would be the best solution:
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. |
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. |
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. |
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;
} |
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 |
Sure, but |
Server Permission: View slash commandsThis 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. |
wow. that seems over the top. but welcome never the less. |
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 |
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. |
I mean, Discord should give time for developers to migrate, and with such an essential feature lacking many will find it hard. |
That's why the deadline was postponed |
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. |
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. |
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 |
iirc they don't plan on modifying the limit |
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 |
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:
Alternatives Considered
Alternative would be to manually check the permissions on each slash command execution. This works currently but has two major downsides:
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:
Additional/custom permission checks (like having a specific role) would still need manual permission checks and "no permission" responses.
The text was updated successfully, but these errors were encountered: