Open ghostdevv opened 2 years ago
Possible solution
/**
* Guards allow you to prevent/allow certain people/groups to your command
*/
guards?: {
/**
* The permissions a member must have to run this command
*
* Works in the sense of a whitelist
*/
permissions?: PermissionResolvable;
/**
* Role specific permissions
*
* Allows the use of a whitelist or blacklist
*
* ? Possible overide for local, if no guildId is provided assume role is a role id.
* ? if a guild id is not provided and the role is just a role name you could bypass
* ? guard by just having a role with the same name in another guild
*/
local?: [{ role: string[]; mode: 'whitelist' | 'blacklist'; guildId?: string }];
/**
* A Custom guard function that returns a boolean
*
* If the function returns true the command will run
*/
custom?: (interaction: any) => boolean;
};
note: would guards have hierarchy (eg: would a local whitelist override a discord perm) or would it be X && Y && Z
Describe the feature
Currently in jelly we expose
guards
which uses the application command permission system, while this permission system is functional it's currently very limited. I want to explore two options:A guard function - this would be the most free choice, the user would be able to do whatever they want with the context to see if a user should be allowed to use the command. This does have the drawback of potentially having to defer more commands slowing down response
Predefined client side guards
Examples
1.
2.