Add Application Permissions Support

[benwoo1110]

About this pull request

Adds support for the slash command permissions. I wanted it for my own bot, got it into a workable state, so I figure I can open a PR to add its feature for everyone if accepted. Feel free to review and test. Let me know of any feedback, happy to accept critics and improve the code 😄.

Changes

• Add setting of default_permission and permissions option for slash command.
• Add get_all_command_permissions and put_command_permissions method to http module.
• Add support for storing permission data in CommandObject.
• Add create_guild_permissions and create_permission utils method to facility defining permissions.
• Add PermissionsData class used for checking for any permission updates since last sync, similar to how CommandData works.
• Add logic to registers permissions in the sync_all_commands method.
• Add SlashCommandPermissionsType enum class to match discord api's ApplicationCommandPermissionType.
• Add relevant documentation needed for the code changes.

Example decorator with subcommand:

@slash.subcommand(
    guild_ids=[750556940127436880, 823454213089787914],
    base="test", 
    base_desc="test",  
    subcommand_group="group",
    sub_group_desc="group",
    name="sub",
    description="sub"
)
@slash.permission(823454213089787914, generate_permissions(allowed_roles=[823851472982376468, 823851440232857600]))
@slash.permission(750556940127436880, generate_permissions(allowed_roles=[778838673666998292]))
async def test_sub(ctx):
    await ctx.send("test_sub")

Checklist

• I've checked this pull request runs on Python 3.6.X.
• This fixes something in Issues.
  • Issue:
• This adds something new.
• There is/are breaking change(s).
• (If required) Relevant documentation has been updated/added.
• This is not a code change. (README, docs, etc.)

[quirky-bluejay]

This is a great start to implementing this!
I've outlined a couple of things that I noticed, but there are a few things with the overall implementation that I would like to see.

permissions to be structured by guild id on the command object
ie

{
  guildid: [ list of guild permission objects],
  guild2id: [list of guild permissions obects],
}

This is because I don't think the current list of dicts that contain a list of guild ids represents how permissions work on the api, it's set per guild, not in a group of guilds and can differ between guilds.
The current approach could also lead to some setting one role id for a list of objects, which best case will fail silently, worst case discord errors because the role doesn't exist on that guild.

To reflect this I think that:

• The permissions parameter of @slash(etc) changed to accept a dict of guild ids to permissons
• Also create a decorator that can be repeated for each guild ie @permission(guild_id = 1, permissions [...])

Also functions should be added to utils.manage_commands that make requests to the api for the three permission related endpoints, as this is the case for command creation

[quirky-bluejay]

What happens if you pass duplicate ids to the manage_commands functions?

which function you are referring to? For generate_permissions and create_multi_ids_permission, I can just cast the ids list to set to remove duplicates.

Sorry, I meant if id's are both allowed and disabled for the same id
I think this would be generate_permissions, but also what would happen if a dict was passed with this?

[benwoo1110]

I dont think there is a need to check for that in code, the false (i.e. disallow) permission just will take precedence.

Also from my testing, this is the behaviour of permission. Let say we have 2 roles called allowed and disallowed.

• user doesn't have any role: command is fade out and no tab-complete. They actually still can run the command on discord desktop if they type out in full. default_permission needs to be set to False for that command to prevent this. (yea a bit weird by discord here)
• user has disallowed role: command is fade out and no tab-complete. The interaction will fail if they try to run on the discord desktop.
• user has allowed role: able to tab-complete and run the command.
• user has both allowed and disallowed role: able to tab-complete and run the command.

[quirky-bluejay]

[....]

• user has both allowed and disallowed role: able to tab-complete and run the command.

I meant if they are the same id. Just wondering what will happen then 🙃

[benwoo1110]

the false (i.e. disallow) permission just will take precedence.

[eunwoo1104]

LGTM, there seems to be no more problems.

[quirky-bluejay]

The @slash.permission decorator doesn't seem to work.
I tested it (code here) and map_permissions in sync_all_commands logged as {}
Using it with the permissions parameter for @slash.slash seems to be working fine.

[benwoo1110]

The @slash.permission decorator doesn't seem to work.
I tested it (code here) and map_permissions in sync_all_commands logged as {}
Using it with the permissions parameter for @slash.slash seems to be working fine.

Decorator order actually matters, the permission decorator must come after, If I am not wrong it's the same case for d.py checks decorators.

[quirky-bluejay]

Decorator order actually matters, the permission decorator must come after, If I am not wrong it's the same case for d.py checks decorators.

Apologies, it's been a while, makes sense when i think about it :(
Although there probably should be an example of it's use in the docs
Possibly in getting started?

[eunwoo1104]

LGTM.

[eunwoo1104]

Merging this pull request. Thank you for contributing!