…ions by Optional annotation
In the past we could not handle a permission in relation to the presence of an optional argument, it forced us to manage it in the body of the command, and could be repetitive and boring, note that it also works with the annotation Default
now supports splitting commands over multiple BaseCommands better
should now only match probable @Default handlers, so @CatchUnknown
can still work in obviously wrong scenarios.
@HelpCommand no longer implies @Default as @CatchUnknown will pick it up
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.
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 ;)
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)
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
The javadocs for Float and Double specify this for the MIN_VALUE:
A constant holding the smallest positive nonzero value of type...
So the true minimum value must be calculated by the negative max value.
Aikar