Currently there has to be the `@CatchUnknown` method in the same class as the `@Default` method.
Without finding any methods for handling unknown commands the default fallback method is the first registered or the class with `@Default` annotated method inside.
Maybe the solution to throw an exception for an unknown command is better.
The BaseCommand tries to execute the command context and if it's not possible it will throw an UnknownCommandException or smth like that.
This context was conflicting with each other over multiple
ACF modules, so if someone wanted to use multiple ACF's in same jar,
it would clash and not work.
The PR to move these was incomplete and this finishes fixing the
context handlers to support new and old.
I want to use own annotations for help implementations (link, tooltips, short description etc.)
I can't access the method directly for the annotations, please add the getter ;)
This PR adds support for the upcoming proxy Velocity.
https://www.velocitypowered.org/
A few note worthy issues:
- Velocity does not provide a static method for its ProxyServer instance, so the instance has to be passed in by the plugin with `new VelocityCommandManager(proxy, this)`
- Velocity does not provide a way to get the Plugin logger with the provided Plugin or PluginContainer, so it must be fetched using `Logger logger = LoggerFactory.getLogger(plugin.getClass());` UNTESTED
- Velocity uses an annotation to signify the main class, meaning it can't be passed around like the Bukkit and Bungeecord JavaPlugin and Plugin. An Object has to be passed in which the PluginContainer is extracted from it using the Proxy's PluginManager
`proxy.getPluginManager().getPlugin(plugin.getClass().getAnnotation(Plugin.class).id()).get();`
Any and all feedback is welcomed and appreciated.
*This implementation is essentially a copy/paste/rename. All code belongs to the original author, except the `ACFVelocityUtil#matchPlayer` which was originally written by md_5 and modified to use Velocity classes.*
Currently the BaseCommand#hasPermission method doesn't actually check if the user has all the required permissions to execute a command, resulting in the following issue:
If user has permission permission.a they can execute:
/example
/example test
/example sub
/example sub testsub
Which is proper but if the user doesn't have permission.a they can only execute:
/example sub testsub
Example code:
```java
@CommandAlias("example")
@CommandPermission("permission.a")
public class ExampleCommand extends BaseCommand {
@HelpCommand
public void help(CommandHelp help) {
help.showHelp();
}
@Subcommand("test")
public void test(CommandSender sender) {
sender.sendMessage("has permission to test?");
}
@Subcommand("sub")
public class ExampleBCommand extends BaseCommand {
@Subcommand("testsub")
public void testSub(CommandSender sender) {
sender.sendMessage("has permission to testSub?");
}
}
@Subcommand("othersub")
@CommandPermission("permission.b")
public class ExampleCCommand extends BaseCommand {
@Subcommand("othersub")
public void otherSub(CommandSender sender) {
sender.sendMessage("has permission to otherSub?");
}
}
}
```
ACF's permission tree can go more complex where a single root command
may have multiple dependent perm nodes.
So essentially ACF does not assign permission nodes to root in bukkit
and the such in a reasonable manner.
With this commit, we try to identify a single unique permission node,
and assign that permission node as the node to use where applicable.
In Bukkit/Sponge, we implement testPermission instead, which does a smarter
look up of all potential commands that root command might execute for the
given issuer, and if they have permission to any of them, then pass as true.
This is much more accurate, so if the issuer has access to no subcommand
then the root command should not be revealed anymore in Bukkit or Sponge.
In bungee, we are best guess at the unique perm node, and if there is
any ambiguity, it will be null and seen by everyone (but still enforces
permission checks)
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.
Aikar