Update to application command permissions

[shaydewael]

Update: changelog and documentation are now live 🚀

Hey all—

Today the new Command Permissions system (has been called permissions v2) has been rolled out to new users—though the UI changes are currently only on desktop. You should see the update when you refresh your client. This launch introduces quite a few changes which can be viewed in the docs PR and changelog entry.

I wanted to post the main changes, especially the breaking ones, here for visibility as well.

Breaking changes

• Bearer tokens are now required to edit command permissions. Bearer tokens are tied to an authenticating user's permissions, and can be retrieved using OAuth. The user must have permission to manage the guild and i ts roles for the Bearer token to be used to edit permissions.
• The applications.commands.permissions.update scope is now required to edit command permissions.
• The batch editing endpoint is being disabled (PUT /applications/{application.id}/guilds/{guild.id}/commands/permissions). Instead, you can fetch the guild commands and edit them individually.

Other major changes

• New CHANNEL permission type
• Increase max number of permissions from 10 to 100
• Adds sentinel value (guild_id - 1) to represent all channels
• Adds two new fields when creating commands: default_member_permissions and dm_permission
• Adds audit log and gateway events

Again, more payload and implementation details can be found in the docs PR (which will be merged and made live later today): #4830

[GoogolGenius]

Is there a way to enforce certain immutable permissions in default_member_permissions for example?

Because it seems that commands, for example, a ban command could still be enabled for users without the BAN_MEMBERS bitwise permission field in a manual overwrite, a potentially dangerous thing to do.

To prevent this we could do backend permission checks, however, it almost defeats the point of frontend integration with Permissions v2.

On second thought, I think the current implementation is fine. It gives a lot of flexibility and basically lets the server admins have the ability to do whatever they want, with bot devs being able to provide a sensible default value. If we still don't want that, we can easily integrate backend checks anyway.