devjake / saltbot-2.0 Goto Github PK

Some bots will often have similar features. If someone were to trigger both commands with one message, they could potentially cause a loop.

bots responding to other bots with say commands -say !say chain with an @everyone mention at the end

To prevent this, simply use the User#isBot() method of JDA to check if the command issuer is a bot.

Currently located here.

When using the bot, a system of 'ranges' should be available. These ranges allow for a permission or command to have a wider - or smaller - area of effect. Ranges come in four types:

• Global
• Guild-wide
• TextChannel-wide
• User-wide

Examples

For each range type, an example has been given. The examples are in terms of permissions.

Global

A permission with a global range will be applied to every user that shares a guild with the bot. As a result, this range should (must) be limited to bot administrators.

Guild-wide

A permission with a guild-wide range will be applied to every user in the Guild that the range was applied in.

TextChannel-wide

A permission with a TextChannel-wide range will be applied to every user in the TextChannel that the range was applied in.

User-wide

A permission with a User-wide range will be applied to a single user. This is the most common range used, and allows for the finest level of permission control and restriction.

Permissions for ranges

Due to the imminent amount of power a range can offer, each range should also require a specific permission to use it. A simplistic system would be to append an applicable range to each base permission. Take, for example, a command that requires the following permission:

salt.commands.currency.givemoney

If an individual is given this permission, they become capable of giving money to any user, from a virtual, infinitely-sized bank of money. With each command, a default range is declared. For this command, the default range is User-wide; the command can only be applied to a single user at a time.

By applying a Guild-wide range, the individual can instead increase the currency of all guild members, simultaneously. Of course, this can be a very powerful tool, so a permission should be required to allow usage of such a range;

salt.command.currency.givemoney.range_guild

Anyone with this permission will now be able to use the command on a Guild-wide range.

Permissions and global ranges

The global range can be very dangerous if not properly managed. If a permission were to be added or removed globally, it can easily cause mass havoc. As a result, the global permission should only be allowed to be applied to a predefined list of users, namely bot administrators.

Global ranges and self-hosted bots

Bots that are being self-hosted should allow for a custom list of users allowed to use the global range. As a note, it is incredibly important that this list can only be edited when self-hosting.

Summary

To summarise ranges:

• A permission can be ranged to provide access to all members of a Guild or TextChannel, or applied to an individual user.
• A command can be ranged to allow for wider coverage in its actions. Commands are ranged by their permissions

Ranges aim to allow for improvements to the efficiency of permission management, as well as improvements to command usages. Increasing the balance of three users would only take a few seconds, therefore disregarding the requirement for ranges, but increasing the balances for 2000 users will take a very long time. As a result, ranges allow for more efficient usage of the bot, as well as for finer tuning of configurations.

Ranges are considered an advanced feature, and should be used with exercised caution.

Every Guild, TextChannel and User has their own set of permissions, which they are capable of controlling and modifying themselves. Although this is a good feature, they should also have a section for 'exclusive permissions'.

Exclusive Permissions

Exclusive permissions refers to a section in the permissions list of each Guild, TextChannel and User, that requires a specific permission to modify. Set perms are required to add, modify and remove any permissions listed here. This system allows for permissions and settings to be applied to an individual, that they are incapable of changing. For example, this would allow for a user to be denied access to a command by a user with permissions to apply the unmodifiable permissions. If the user attempts to modify this permission, they would be incapable of doing so.

Add a 'universal' and 'local' prefix. A global prefix is a prefix that works regardless of guild, whilst a local prefix functions based upon the current guild.

This ensures that users are able to better use the bot across guilds, as well as helping those who change the prefix and forget it.

Perhaps add permissions to allow guilds to disable the global prefix (?)

Restricting abilities to premium-users only.

The bot should be able to play music, as well as streaming audio from radio stations and live radios. Use this library.

Allows for filtering of message content and automated responses.
See issue #4 for further details.

Unit tests should check for:

• Handling of null values
• Handling of correct input(s)
• Handling of excessively-large input(s)

When a 'generation' time is calculated, it sometimes takes less than a millisecond. This should be converted to "<1ms", rather than "0ms".

This command should be capable of locking down the entire bot's operation, or preventing the bot from functioning in a specified guild. An optional error message should also be capable of being displayed, with a configurable message.

This command should be able to search through the bot's own JavaDoc, as well as allowing for the addition, removal and management of alternate JavaDoc, for different projects.

Allow users to create a filter, and manage its responses.

Filters should include:

• Message text
• The URL of any posted resources (filterable by image, video, gif or generic URL)
• The poster of the message
• Any mentioned users (also include @everyone and @here mentions)

Responses should include:

• Banning the user (with configurable duration)
• Muting the user (with configurable duration)
• Kicking the user
• Deleting the message(s)
• Mentioning another user
• Posting a message (with configurable channel and content, as well as perhaps through PM to specific individuals)

Posted messages should support the following references:

• A predefined group of users (allows for staff to have content automatically brought to their attention)
• $RULES - The 'rules' of the guild
• $HELP - The help command for the bot
• $URL[No.] - A predefined URL, followed by a number. This allows for multiple URLs to be defined.

Finally:

• All actions, references and filters should also be combinable.

For the purpose of maintaining good security, a guild should be able to choose to enable or disable high-level permissions. When this is done, certain permissions are marked with different levels. Permissions that easily allow abuse of the bot are marked with a level of ABUSABLE.

When assigning these permissions to an individual, users with perms can determine how to respond, such as requiring verification from a third party (another user with permissions to verify).

May also require adding (or modifying) the code of the Configuration system, to allow for individuals to be added.

Allow every user and guild to bind a set command (with arguments, optionally) to a custom command. Each bind should be stored relevant to the guild or user who authored it.

When calling on binded commands, the event that was fired from calling the command should be passed to the bound command itself.

Allows an individual to select a message, either by ID, or entering the username of the person who entered it. If a username is entered, the most recent message from them in the current textchannel (unless specified to a guild in general) should be used. A range of messages should also be selectable by entering either a range of IDs, or a range of timestamps.

These messages can then be forwarded to a specified channel in any guild. Also need to add permissions for this command.

Issue

In the following example, a user might spend 10-20 minutes creating a powerful command that performs impressive functions. If another individual wants to use the same command, they would have to either reverse-engineer the initial command, or follow the same process of creating it. This is inefficient.

Proposed solution

By issuing a command, an individual is able to list what custom commands another user has created. An individual can then request to have a command shared with them (if the command is marked as public). If the author agrees, then the requester is automatically given access to the command.

Note

All custom commands should be capable of being marked as public or private. By default, a command will be private. Public access controls if it can be seen on a user's list of commands.

Guilds should be able to control if individuals can use, view and share their custom commands. Guilds may want to enforce strict anti-automation policies, and this would allow such a feature.

A creator of a command should be able to keep statistics on how well their custom commands are performing. For example, they can view how many users are using it, across how many guilds, and how often.

Host the JavaDoc documentation online, to be easily accessed and queried.

Add a specific range of Exception types exclusive for Custom commands. When a user creates a custom command, they can specify for exceptions to be thrown at certain points. Each exception will be capable of providing details to the user about what they did wrong.

If the exception contains a custom message, it can also be displayed to the user using the command.

The language system should allow each user (and each guild) to state their chosen language. Each user should be able to override the guild's chosen language to their own (with permissions to disable this). Each guild and user should be capable of creating and modifying their own language system.

This would allow for the bot to post custom messages to each guild. Each feature should also come with their own relevant permissions.

...as in the title.

When adding a custom command to a guild (not to a user, as a user will automatically gain full access to their own commands), the guild should be able to specify a permission for the command. This will allow them to gain control over who can and cannot use it.

Permissions shouldn't have to be specified. If they aren't, everyone is able to use the command.