Slash command permissions not affected by Role viewing

[LukeHankey]

I wasn't entirely sure where to post this so I thought asking the question here instead was best.

When registering slash commands and setting permissions for only specific roles to use them, when viewing the server with that role, you still can't use them which I guess makes sense but the opposite is also true - You can still use them even when viewing with a role that doesn't have permissions to use the slash command. I figured this would be useful for checking that the commands are actually disabled/enabled for the specific roles.

Is there any reason why this isn't implemented considering the main reason that this was added?

[ckohen]

View as role is completely client side, and I don't think the client recalculates application command permissions when you enter / exit view as role. It seems reasonable that it isn't the case currently anyways, since in that very same article it mentions the things view as role applies to and there is no mention of application commands.

However, I think its is possible this may actually get implemented with the permissions changes proposed in #3581 as those permissions would actually be client side.

[advaith1]

I don't think the client recalculates application command permissions when you enter / exit view as role

yes it doesn't currently, which is the point of this feature request (which I would consider a bug report)

your screenshot just shows some example use cases; view as role is intended to fully act like you only have the selected role

[ckohen]

view as role is intended to fully act like you only have the selected role

I'd actually have to completely disagree with this, anything that involves interacting with the API is unaffected by view as role (and that's a lot).
Here's some pretty big examples:
Search
Sending messages with role / everyone / here mentions
Sending messages with links that embed
Sending messages with external emoji / stickers
The voice restrictions mentioned in the article
And plenty more

Interestingly enough, Loading messages in a channel you cannot view (via using back buttons or other) doesn't work because the client simply doesn't send the request to load messages, but you can still send messages there.

Even if the command was disabled, you'd still be able to send it by typing it out (as noted from other bug reports of disabled commands, the API errors with missing permissions, not the client)

My guess is the current iteration of application command permissions does not store the full permissions anywhere client side (since they're not on the command object) and just gets a list of enabled and disabled commands for your current user / roles.

I kinda forgot this was a feature request and not a bug report. It makes more sense now that I approach it from that angle. I've become accustomed to using an alt account to do role based testing because my bot has no way of knowing I'm using view as role, but application commands do provide an avenue to make that a possibilty.

[IanMitchell]

Huh, this was one of the first things I did when I got hired. If it's regressed, that's an introduced bug - I'll try and carve out some time to fix that. Going to migrate this into an issue

[IanMitchell]

#3952