Suggestions: Small Utilities

[gdude2002]

I've created this issue so that people can suggest small utilities without creating an entirely new issue for them. Just leave a comment below, and I'll have a look when I can.

Next up

• Range support for number-based list converters
• A way to provide a response for people that fail paginator checks
• A way to handle unknown components (at the component registry level)
• Default guild ID for command registrations, at the extension level
• A translate overload for ValidationContext without the bundle parameter

Implemented

• Expose member edit features as individual functions, for situations where you don't want to do more than one edit at once
• Convenience function to get a thread's parent message using its ID, if there is one
• Repeatable scheduled tasks: Add repeatable tasks #140
• Channel/guild NSFW check
• Exposing appPermissions on command contexts
• A way to differentiate members in the guild with users supplied outside the guild.
• Bot owner check

[Galarzaa90]

This is probably not "small", but something that would be really nice to have is command cooldowns and concurrency limits

[Jamalam360]

As said on Discord, I'd like a method on the Scheduler class to repeat a task every X Duration. E.g. scheduler.repeat(3) { println ("hello") } would print hello every 3 seconds until cancelled.

[gdude2002]

@Galarzaa90 Please see #27 and #36 - cooldowns would be great to have, but I can't wrap my head around an implementation for it, which is why it hasn't been done.

@Jamalam360 Added, see #140

[Jamalam360]

Thanks

[Stonedestroyer]

For check context some sort of isOwner check that gets application owner and if in a team all owners and passes check if it was the executer, also as application info is a rest some sort of cache or logic here.

NSFW check would also be cool built into check context.

[Stonedestroyer]

A way to handle unknown components, can be useful if bot restarts and user is not hit with application did not respond error but ephemeral message explaining what happened.

[Stonedestroyer]

A way to have default paginator accept a default check or some boolean that allows sending a response to non-authorized users of the paginator that this can not be used for them for UX purposes.

[Galarzaa90]

Exposing appPermissions on command contexts? This is really useful because these permissions are already solved with channel overwrites and all that, so seems like an easy way to get bot permissions.

They can already be obtained from event.interaction.data.appPermissions, but exposing them on the command context would be nice.

Reference: https://discord.com/developers/docs/interactions/receiving-and-responding#interaction-object-interaction-structure

Discord Developer Portal

Discord Developer Portal — API Docs for Bots and Developers

Integrate your service with Discord — whether it's a bot or a game or whatever your wildest imagination can come up with.

[gdude2002]

Convenience access to appPermissions and channel/guild NSFW checks have been pushed and will be available shortly. The push also includes an or { } block you can use in your checks.

[Stonedestroyer]

A way to differentiate members in the guild with users supplied outside the guild.

Currently optionalMember returns both null for both user outside guild supplied and no arguments supplied. Considering Discord only supplies a USER object and does not tell you if a MEMBER was in the guild.

Use-case:
Let's say you have a bank command and you wish to give user an error that this user is not in the guild, right now it would act like the argument was not supplied and return null, a way to resolve it is to use a optionalUser with a custom check rather than optionalMember.

Having an toggle in optionalMember to do a custom check or tell user that the user supplied is not in the guild and still return null could work.

The major reason is to alert that a user that is not in the guild was supplied to the optionalMember therefore making it easy for user to see what they did wrong.

[gdude2002]

A way to differentiate members in the guild with users supplied outside the guild.

I've given a shot at this, but I think it needs some testing. You'll have to let me know how it goes. It'll be up in about 15 mins or so.

[Galarzaa90]

Just like Extension has a allowApplicationCommandInDMs property. Maybe a nullable defaultGuildId (or a better name) property to make all commands in an extension be guild commands by default?

Could be useful for Extensions for specific guilds.

[gdude2002]

Is this a simple suggestion, or is there a use-case you have in mind?

[Galarzaa90]

Is this a simple suggestion, or is there a use-case you have in mind?

I think both. In my case, I have all global commands, but I have this Extension for staff related commands, and these are guild commands in our support server. So each command here has guildId set. I also plan on adding another extension for a big community my bot is in, for some special commands.

So of course it is easy to just have the snowflake as a local variable in the extension and then use it on every command declaration, but I figured since we have allowApplicationCommandInDMs as a extension-level setting for commands, a defaultGuildId would also make sense for such cases.

[Galarzaa90]

A translate overload for ValidationContext without bundle parameter, to use defaultBundle without needing to pass it.

Just like: CommandContext.translate has this overload.