devjake / saltbot Goto Github PK

A very simple command to allow the disabling of notifications, either permanently or temporarily. Would disable all bot-caused notifications that cause a disruption to the user specifically (direct PMs, tagging in messages, etc.). Bot actions that influence multiple users would only be disabled if all users have stated they wish to receive no updates.

Command can also have a time parameter appended (E.G., .. d:5m, rt:20m (d:Duration, rt:Repeat Time), would disable all notifications for 5 minutes, and repeat every 20 minutes.) The Repeat Time must be greater than or equal to the Duration time. Failure to check will result in various errors.

A help command...

Various config types (system, guild, user, etc)

Guild settings dominate -some- user settings (but some user-settings are unique to the user config, so cannot be listed in the guild config).

Multi-action commands, are commands that allow an operation to be repeated over multiple objects.

Multi-command inputs must be separated by a semicolon (by default). This character (or set of characters), can be altered in the guild-wide config.

Possible plans to allow individual users to customise their separator can be added, but various checks will need to be performed, to ensure the separator is legitimate ('allowed', being uncommon characters, up to a certain limit).

Example:
.mute [Username;Username;ID]

The example above shows multi-action commands in use, with the .mute command. The example highlights two important elements; entries (single or multiple), do not finish with a semicolon, and entries may (but will not always be), of different data type. In the example, the input ranges from usernames as String formats, or user-IDs as String formats.

Example:
.mute [Username;ID] [Channel1;Channel2] [Reason1;Reason2]

The second example shows multiple parameters using multi-action commands. Various outcomes can occur, either each user is muted on both channels, for two reasons, User1 is muted on Channel1 for Reason1 (and repeating for User2), or any further combinations.

The guild-unique config will allow for the selection of either successive-mode (User1 matches to Channel1 and Reason1), or disjunctive-mode (User1 and User2 receive the outcome of the command, with the result of a successive-mode operation on both Channel1->Reason1 and Channel2->Reason2).

Much with the previous suggestion of user-customisable separators, the user may also be able to choose how their command will handle parameters.

Permissions

Permissions are assigned, and allow a user to perform an action. Permissions are required to assign permissions, and at least one guild-member must have the permissions to add permissions.

Example:
guild.user.viewlog
guild.user.*

Restrictions

Restrictions work as the inverse of a permission. They restrict a user from performing an action. This is ideal for situations where a user is assigned wildcard permissions (*), but a specific sub-perm needs to be blocked.

Permissions are classed as 'positive', Restrictions are classed as 'negative'. An overlapping permission and restriction will result in a dominant restriction. If a debugger is added, it could identify when this problem appears.

Example:
-guild.user.viewlog
-guild.user.*

Enforcements

Enforcements ensure that a user fulfils certain requirements. When banning a user, it is required for a username (or user ID) to be specified. The reason and duration are optional. These optional parameters can be made compulsory, with Enforcements.

Enforcements are different from Permissions and Restrictions, as they work with the parameters of a command, rather than the command itself. Therefore, permission names won't overlap with Enforcement names.

Example:
guild.user.ban.reason //Must state the reason for a ban
guild.user.ban.duration //Must state the duration for a ban

Allows commands to function across guilds. Only certain commands will work, depending on their function.

The user must have the correct permissions for cross-guild commands, on every guild to work alongside. Both guilds must also reference the ID of the other guild in their guild's config. This ensures that the owners of both guilds (or the assigned admins), must both agree to cross-guild commands.

Commands, by default, are local to the guild they are sent in. To make a command cross-guild, a specific tag must be appended to the end of the command. (Such as "--cg").

The user of a command can also specify the IDs of the specific guilds to operate alongside.

Any commands run must have the correct permissions on all corresponding guilds. A failure to have correct permissions on one guild will not completely stop the command from running.

Potentially allow the bot to stream audio files, making the bot more multi-purpose --look into, as issues have occurred in the past