This PR is to allow users to unregister commands from the `JDACommandManager`
Currently slightly flawed, needs research. When re-registering it spits out a load of messages like so:
```
SEVERE: [ACF] ACF Error: settings registered subcommand boss role for root command settings - but it is already defined in settings
Sep 20, 2018 3:58:31 AM com.algorithmjunkie.freelance.gachapon.acf.JDACommandManager log
SEVERE: [ACF] 2 subcommands of the same prefix may not be spread over 2 different classes. Ignoring this.
```
Not sure if this is just for me, or if it's for all.
The code is now checking for placeholders, that are not replaced. This would also warn the dev if he completely forgets to register a replacement.
The downside of this is, that any %.* kind of pattern, that is NOT supposed to be a replacement will cause an error message. But since I couldn't come up for a reason to include % in any of the Annotation values other than a replacement, I decided this is much easier than checking all "old" commands when a replacement is registered.
Alternatively, I could collect all these unreplaced replacements and check against the collection when a new one is registered. This would not warn a dev that forgot to register the replacement, but on the other hand still allows the use of %. Please tell me what you think.
resolves#160
You must pass your own exception handler in order to do this.
Implementors need to be sure to log if its not a desired throw or
otherwise you will have silent command failures.
Improve help output for commands split over multiple base commands
Fix help last page detection
Fix missing argument on Player Context Resolve
Expose registered root commands
When @ mentioning someone in Discord, if you manually click the user's name then the ID will be in the chat field as "<@!...>". However, one can _also_ mention a user like so "<@...>".
This PR handles both cases.
In a previous PR, some contexts were not changed from **IssuerOnly** to **IssuerAware**. This has been patched.
I've added a context to resolve a Role. It makes use of the next item I added.
The CrossGuild annotation is used to signify whether or not the context is to be interpreted from a guild perspective or a bot perspective (i.e. all guilds). This annotation could probably be better named.
This pull request is an initial attempt at implementing permission for commands for the JDA module.
It includes one added file, **JDACommandPermissionResolver** which implements CommandPermissionResolver.
I created a map to store the Discord permission offsets stored mapped by their kebab-cased name (i.e. "ADMINISTRATOR" becomes "administrator", "MANAGE_SERVER" becomes "manage-server".
The implementation of `hasPermission(JDACommandEvent, String)` is fairly simple:
- Get the issuer's Member object
- Check if it's null; if so, return false.
- Get the permission offset from the aforementioned map
- Check if it's null; if so, return false.
- Return whether or not the member has the permission.
---------------------------------------
This PR allows new commands to use the `@CommandPermission` annotation like so:
```java
@CommandAlias("test|t")
public class Command extends BaseCommand {
@Subcommand("admin|a")
@CommandPermission("manage-server")
public void adminCommand(MessageReceivedEvent event) {
//...
}
}
```
Because Discord does not support coloring messages outside of embeddable fields, it is safe to use a simple message formatter than just returns the message itself.
As I was testing my previous PR, I noticed messages coming through with coloring symbols (e.g. `<c1></c1>`), and each only went up to `c3` maximum. Finally, I figured out these were colors that needed to be handled in each case.
To remove colored messages from Discord, the message formatter is passed three empty strings for each of `c1`, `c2`, and `c3` respectively.
Finally, the default formatter is set inside of `JDACommandManager` but can always be overridden by the user.
Aikar