Skip to content

Allow restricting commands to arbitrary permission #6

Description

@Saladoc

What?

Allow restriction of a command to an arbitrary permission understood by discord (or rather javacord/jda) without having to create a custom Restriction implementation.

Why?

Use cases will most commonly be cases where a bot command reproduces a discord (moderation) functionality and should only be made available to users that have that capability, like:

  • Restricting a cleanup command to users with the MANAGE_MESSAGES permission.
  • Restricting a mass timeout/kick/ban command to users with the MODERATE_MEMBERS/KICK_MEMBERS/BAN_MEMBERS permission

Providing a functionality like this directly in command-framework will standardize handling. It will allow other code to better inspect the RestrictionChain and from that derive the actual permissions required - this will aid, for example, if slash commands are to be registered with the appropriate default permissions.

What it...

should be

  • Provide a class or interface for parameter based restrictions.
  • Allow to specify whether the ADMINISTRATOR permission being present should also be accepted (defaults to true)
  • Provide an annotation like RestrictedToPermission("MANAGE_MESSAGES") or RestrictedToPermission("MANAGE_MESSAGES", acceptAdmin=false)

might be

  • Implementation-specific with different annotations / classes / interfaces for Javacord and JDA accepting their respective permission types
  • Extensible for custom string-based permission systems (provided a resolver is supplied)

should not be

  • anything more than that

Problems / Thoughts

Such a system is not supported with the current annotation / restriction concept as far as I can see, so it will require some thought on how to properly integrate it. Maybe it could be implemented by adding a phase to hook into during creation of the commands where a user-provided bean could transform the command and for example check for custom annotations, parse them and add elements to the restriction chains - but those wouldn't play nicely with the @{All,Any,None}Of annotations.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions