Added

New ?plugin registry compact command which shows a more compact view of all plugins.

Plugin Registry

Plugin developers can now make a PR to include their plugin in the plugin registry command.
Add your plugin in the plugins/registry.json file in the main repository.

Changed

?debug command now shows the most recent logs first. (Starts at the last page)

What's new?

• New error message when using thread-only commands outside of threads.
• ?unnotify, ability to undo ?notify.
• ?notify and ?subscribe now accepts other users.

Changes

This update contains mostly internal changes.

• Implemented support for the new discord.py v1.1.1.
• Improved help text for most commands.
• Completely revamped help command, few user changes.
• Removed abc (internal).

What's new?

New oauth whitelist command which allows you to whitelist users so they can log in via discord to view logs. To set up oauth login for your logviewer app check the logviewer repo.

Changed

• Ability to force an update despite having the same version number. Helpful to keep up-to-date with the latest GitHub commit.
  • ?update force.
• Plugin developers now have a new event called on_plugin_ready, this is coroutine is awaited when all plugins are loaded. Use on_plugin_ready instead of on_ready since on_ready will not get called in plugins.

What's new?

• New config variable guild_age, similar to account_age, guild_age sets a limit as to how long a user has to wait after they joined the server to message Modmail.
• guild_age can be set the same way as account_age.

Fix help command bug when using external plugins.

Fix the teams permission bug.

Do not use this release.

Changed

Commands now have better error messages, instead of just sending the help message for a command when an argument fails to be converted to its specified object, the bot now says things like "User 'bob' not found" instead.

Un-deprecated the OWNERS config variable to support discord developer team accounts.

New Permissions System

• A brand new permission system! Replacing the old guild-based permissions (ie. manage channels, manage messages), the new system enables you to customize your desired permission level specific to a command or a group of commands for a role or user.
• There are five permission levels:
  • Owner [5]
  • Administrator [4]
  • Moderator [3]
  • Supporter [2]
  • Regular [1]

Usage

You may add a role or user to a permission group through any of the following methods:

• ?permissions add level owner @role
• ?permissions add level supporter member-name
• ?permissions add level moderator everyone
• ?permissions add level moderator @member#1234
• ?permissions add level administrator 78912384930291853

The same applies to individual commands permissions:

• ?permissions add command command-name @member#1234
• ... and the other methods listed above.

To revoke permission, use remove instead of add.

To view all roles and users with permission for a permission level or command do:

• ?permissions get command command-name
• ?permissions get level owner

By default, all newly set up Modmail will have OWNER set to the owner of the bot, and REGULAR set to @everyone.

Breaking

When updating to this version, all prior permission settings with guild-based permissions will be invalidated. You will need to convert to the above system.
OWNERS will also get removed, you will need to set owners through ?permissions add level owner 212931293123129 or any way listed above.

New Command

• A ?delete command, which is an alternative to manually deleting a message. This command is created to no longer requires manage messages permission to recall thread messages.

Changed

• The help message no longer conceals inaccessible commands due to check failures.

Changed

• Logs search command will search through log keys as well now.
• For example, ?logs search e7499e82f8ff.

What's new?

Stricter fallback genesis embed search.

Changed

How modmail checks if a channel is a thread:

1. The bot first checks if the channel topic is in the format User ID: xxxx, this means it is a thread.
2. If a channel topic is not found, the bot searches through the message history of a channel to find the thread creation embed. This step should never yield a thread for a normal user, but in the case of another bot messing up the channel topic (happened to a user before) this extra step was added.

What's new?

Added a config option reply_without_command which when present, enables the bot to forward any message sent in a thread channel to the recipient. (Replying without using a command)

To enable this functionality, do ?config set reply_without_command true and to disable it, use ?config del reply_without_command.

Changed

The move command now only requires manage_messages perms instead of manage_channels

Fixed

An issue where a scheduled close would not execute over a long period of time if the recipient no shares any servers with the bot.

Changed

All support for Modmail API (api.modmail.tk) has terminated.
If you're still using api.modmail.tk, you will need to migrate to the self-hosted database
option ASAP. Your bot will not work unless you switch to the self-hosted option. Refer to the installation tutorial for information regarding self-hosted Modmail.

If a member leaves/joins (again) while they are a recipient of a thread, a message will be sent to notify you that this has occurred.

Fixed

• Emergency patch of a SyntaxError.

What's new?

Added the ability to change the default close message via the introduction of two config variables.

• thread_close_response - when someone closes the thread.
• thread_self_close_response - when the recipient closes their own thread.

They will be provided by string variables that you can incorporate into them:

• closer - the user object that closed the thread.
• logkey - the key for the thread logs e.g. (5219ccc82ad4)
• loglink - the full link to the thread logs e.g. (https://logwebsite.com/logs/5219ccc82ad4)

Example usage would be: ?config set thread_close_message {closer.mention} closed the thread, here is the link to your logs: [**`{logkey}`**]({loglink})

What's new?

Added the ability to enable the recipient to close their own threads. This takes place in the form of a reaction that the user can click to close their thread. This functionality is now enabled by default.

To disable this, do ?config set disable_recipient_thread_close true