added setMode to documentation, added error handling with templated exception for set mode and refactored some feature config related methods (changed the equal to be case insensitive)

This commit is contained in:
Sheldan
2020-05-16 21:46:10 +02:00
parent d2264937b2
commit b0ab88d143
15 changed files with 84 additions and 29 deletions

View File

@@ -101,6 +101,10 @@ Make a role immune against a command::
Enforce the role restrictions of commands::
* Usage: `restrict <featureName|commandName>`
* Description: Causes the role restrictions for a all commands in the `feature`/the `command` to be in effect again.
Changing the mode of a feature:
* Usage: `setMode <featureName> <newMode>`
* Description: Changes the mode of feature `featureName` to `newMode`.
.What does it mean if a role is immune?
A command can take a member as a target, for example `ban`. If a role is considered immune, this means, if the member which is the target of the command has the given role, this command will fail. Not all commands support this feature, but only the following:

View File

@@ -29,7 +29,8 @@ System configuration:: Some properties can be configured while the bot is runnin
In the respective features they are noted under `Relevant system configuration`.
In order to change this you need to use the command `setConfig` with the provided key and the new desired value.
Emotes:: The features have section of the keys of used emotes in the feature, you can change this emote with the `setEmote` command.
Feature Modes:: Features can have different modes. This means, a feature behaves differently if the mode is changed. For example: `modmail` has two modes: `log` and `noLog`.
In the mode `log` mod mail threads wil be logged into the post target `modmailLog` while in the other mode, this does not happen. This consideration of the modes does depend on the implementation of the features.
== Features
include::features/core.adoc[]