boscojared / disparse Goto Github PK

If there is no long flag present, disparse should not fail. Only a short-flag should be required to use flags. Might be a bug

test the body out

It would be nice if --number=5 or -n=5 also worked along with --number 5 and -n 5

This involves work in all of the modules of disparse, namely:

• disparse-core
• disparse-jda
• disparse-d4j
• disparse-smalld

The goal of this feature is to abstract sending a direct message to a user. In disparse-core, there should be a method added to AbstractDispatcher which is an abstract method left to be implemented by each of jda, d4j, and smalld.

Then in each Dispatcher class for each module, there will be an implementation specific to the underlying library. Also, don't forget about the Dispatcher that is in disparse-core/src/test/java/disparse/discord/TestDispatcher.java

This feature can be tested manually for now using the disparse-testing module.

This issue proposes to add an optional step in the Dispatch.Builder to auto generate a commands.md file in the root directory.

The default for this option should be false.

The file structure should look like this
Template:

# Commands

## Command Name

Command Description

* **Cooldown:** Command cooldown

* **Required Permission:** Permissions if specified

* **Required Role:** Role if specified

#### Arguments

* `shortname`, `longname` : argument description

#### Usage

`example usage from usage annotation`

Example:

# Commands

## mute

This command will mute the target user

* **Cooldown:** 5 seconds per User

* **Required Permission:** Ban

* **Required Role:** Moderator

#### Arguments

* `-u`, `--user` : The target userid to mute

#### Usage

`!mute -u 0123456789`

If any information is not provided (permissions, roles, cooldown, they can be marked as N/A)

Feature Description: Currently, there is a line in each Dispatcher implementation that looks similar to this. This line explicitly checks if the incoming author is a Bot, and stops processing a command.

While this is a sane default, it could perhaps be desirable to be able to accept bot commands. This should be added in some way to the AbstractDispatcher which will put us in a position to provide a default implementation of the dispatch.

Usage:

Dispatcher dispatcher = new Dispatcher.Builder()
    .allowIncomingBotMessages(true)
    .build();

The default will be false.

Modules Affected: All modules are affected. core, d4j, jda, and smalldwill need to be changed. Therefore, the module in the commit message must be [core] or [core/dispatch].

Out Of Scope:

Moving the entire dispatching logic to the AbstractDispatcher. This will eventually be done; However, it is out of scope for this issue. Keep it simple.

Making the boolean on a per-guild basis. This will also eventually be done, but is out of scope. This issue is only dealing with the configuration globally for the bot.

Requirements Checklist:

• Add allowIncomingBotMessages to Builder
• Default the boolean to false
• Change the check to respect the boolean. True means bot messages are able to be executed

As always, be sure to read the contributing guidelines in the root of the project to understand the commit message template and other considerations.

This feature / task write-up is in response to the original issue posted here.

Feature Description: Currently, @Flag types can be put over the following types of fields: Integer, Boolean, List, and String. In the case of Integer and Boolean, only the wrapper types are supported. Disparse should be extending to be able to set the values of fields that are of type int or boolean. After this feature, the total fields supported by @Flag will be Integer, int, Boolean, boolean, List, and String.

Reproduce:

1. Create a blank discord bot project
2. Create a class named PrimitiveCommand.java

public class PrimitiveCommand {
    
    @ParsedEntity
    static class PrimitiveOpt {
        @Flag(shortName = 'n', longName = "number")
        int number = 0;
    }

    @ParsedEntity
    static class WrapperOpt {
        @Flag(shortName = 'n', longName = "number")
        Integer number = 0;
    }

    @CommandHandler(commandName = "test")
    public static DiscordResponse test(WrapperOpt option) {
        return DiscordResponse.of("You chose number:  " + option.number);
    }
}

Copy paste the above code into the class, resolving the imports as needed. When PrimitiveCommand::test accepts WrapperOpt the command will work because it is using the wrapper Integer type. When PrimitiveCommand::test is switched to use PrimitiveOpt the command will throw a stacktrace due to not yet supporting the int primitive type in Disparse.

Modules Affected: This is a core issue only, and therefore changes should only need to be made into disparse-core. The commit message should following the contributing guidelines and be something like: [core] support primitive types as flag fields.

Where to look: Utils.java has a few conditions explicitly type checking the field and setting to an enum. This would need to be updated first.

CommandRegistrar.java is where the command will eventually be dispatched with the correctly set values. This may or may not need to change after Utils.java is changed to accept both Integers and ints.

Tests: Ideally a PR would include a few tests in DispatchIntegrationTests.java but ultimately it is not required.

As always, read the contributing guidelines and/or reach out on Discord @bosco#8564 for help or discussion.

some text to show it works

The Problem

Middleware could potentially change the permissions of commands by returning false in certain conditions, especially if the use-case is more complex than supported by Disparse. The help command runs without considering anything about middleware's return value and therefore you could show a command to a user through the help command they are unable to run. This is poor UX and can confuse the user.

The Solution

We can filter the command collection to only hold commands that would pass through the middleware for the current invocation. This can be done by modifying the AbstractDispatcher's help method here to run through the middleware chain and filter out any commands that return any false's.

Getting Help

To claim the issue and get a little more support, feel free to ping on Discord @Bosco#8564 or join the Discord for Disparse's development here.

Currently sendCooldownMessage accepts a boolean type. See docs

This feature request proposes creating an Enum to extend functionality.
disabled - cooldown message is not sent
reaction - invocation command receives a reaction with "🕒" indicating the command is on cooldown.
enabled - cooldown message is sent.

Currently checking of the sendCooldownMessage field is done here

Problem

Assume a command named foo accepts a repeatable flag with the following definition:

@Flag(shortName = 'r', longName = "repeatable")
List<String> repeats = new ArrayList<>();

This means we are able to invoke this command like: !foo -r "first" -r "second" -r "third"

Our repeats field will now show ["first", "second", "third"] which is good and expected.

If we mix-and-match the longName with the shortName; However, we see that the order we receive is unexpected and surprising: !foo -r "first" --repeatable "second" -r "third" now shows that our repeatsfield is ["second", "first", "third"]

Mix-and-matching repeatable flags by shortName and longName should be supported.

Where To Look

In the disparse.parser.Parser there is a parse method that handles parsing out short flags, and long flags, and then finally merges them into one map using Map#merge which does not respect the initial order of the flags in the original args.

Parser should be the only file needing to be changed for this issue.

Testing

There already exists a test in the integration tests here that documents the incorrect behavior. This test will fail when the parser correctly handles this case, and this test should change the order of the list elements to make it pass ( thus proving that the change was successful ).

The commit name should be prefixed with [core/parser] and as always, be sure to read the contributing guidelines in the root of the project to understand the commit message template and other considerations.

Super cool issue body

Currently a @Flag will work on an Integer field, but not with an int field. The exception thrown indicates it's trying to set an int field to a boolean

some text to show it works

It's useful to have longer help descriptions for commands. It's useful to have short descriptions as a summary of commands.

Tools such as Javadoc and click allow long descriptions and use the first sentence as the short description.

On the help page for the full bot, use the first sentence of the description as a summary
On the help page for a specific command, use the full description (this also means it's probably better off not in the title of the embed, but just as plain text)

Also possible is supporting summary in the @CommandHandler, so that it can be explicitly given if preferred, but defaulting to the first sentence of description if it's not given.