Guards Overhaull

[ghostdevv]

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

export default command({
   guards: {
       validate: ({ interaction }) => {
          return true; // Wants a truthy response to be allowed and falsy to be disallowed
       }
   }
})

export default command({
  guards: {
     mode: 'whitelist',
     
      local: {
         roleNames: ['support']
      }
  }
})

[cainthebest]

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

[ghostdevv]

Folding #227 into this issue: We should support guards in some form on all interaction based components if possible (needs shaping)