discord-modmail/modmail

A Modmail bot for Discord. Allowing safe moderator conversations with server members one server at a time.

modmail's Issues

discord.py: explore possible forks

Description

Look at migrating to a fork of discord.py

As we all know, discord.py is no longer maintained, and discord.py could break at any time. With the upcoming timeouts feature, it seems like time to look for a library that is currently maintained.

I am a fan of disnake, except that currently has a few bugs with unawaited coros.

Merge discord-modmail/site into modmail

After lots of discussion, we've decided that the best way to manage this project is to merge the site into the bot.

This comes with multiple benefits, as we don't have to maintain database schemas on both repos, have a seperate backend for each, and makes it easier to deploy.

As of now, it is our goal to make the site and bot mostly independent from one another, and running the site shall be optional.

Remove starlette-discord and write our own auth

We have a lot of dependencies, and starlette-discord is still under development. It would make more sense to implement our own authenticate and check system where we would have more fine control over it.

Config fails to load

[Extension Metadata]: small refactor & add load attribute

Is there an existing issue for this?

• I have searched the existing issues and there is no existing issue.

What is the feature?

Overview

While our extension loading system is able to handle multiple different cases, we'd like to add support to the metadata to be able to set files to not load when the bot is loaded, and load them at a later time.
We'd also like to have extensions and plugins which are walked, deemed valid, but not loaded. This allows us to have them in the system, but not have them loaded at the time.

Implementation

The majority of the walking takes place in modmail/utils/extensions.py, but a bit of it also takes place in modmail/utils/plugins.py

Both of these metadata loaders should be refactored to load metadata into a dict, in order to make easier to expand over time. Anywhere that these wailking methods are used will need to be updated to use the dict, and where EXTENSIONS or PLUGINS global variables are used.

Would you like to implement this yourself?

No, someone else can implement it

Permission system

Description

In order to manage commands and who is allowed to use what, there should be a custom permission system which can mutate the permission requirements for every command.

This should be somewhat easily doable with custom checks and a global bot check. https://discordpy.readthedocs.io/en/master/ext/commands/api.html?highlight=check#discord.ext.commands.Bot.check

Each command and cog, plus subcommands should be able to be modified who can run them. There should be defaults as decorators on each command or cog_command_check.

In addition, this system should work with interactions and slash commands, with the fork that is chosen as a result of #129

This depends on both #75 and #107

Remove website

After internal discussion, I've decided that there will not be a website or a dashboard.

This is because modmail threads will also be Discord threads. Using these allows for the contents of the thread to be archived in discord. No longer do we need to have a website, or most of the database.

The database is still necessary for bot configuration, and to store some metadata about threads to improve ease of use, but other than that, threads and such will all live in discord.

Tasks:

• Discuss whether or not to remove website (this issue)
• remove website from source code

Add flake8 and precommit

Currently, there are no precommit scripts or anything to ensure the code is linted upon commit.

This is urgent to be added before more commits are made which don't follow pep8.

Rewrite configuration system

The configuration system is a mess. Rewrite it.

Main feature: database

We need a database module to store things persistently, such as thread state.

Things that need storing:

• Thread metadata (originating message, thread ID, user )
• Thread message data (who wrote, was internal, highest role, message content, reactions? Attachments? )
• Config data (should just be a string/string KVS for now because that's how db config works)

These things should be server-keyed so in the future we can support multiserver if we want.

feat: Write test suite for bot

discord bot needs a test suite, the basis of said test suite already exists, but there is no test suite.

Depends on #29

[tickets/threads] Dm system to relay messages from dms and back again

Is there an existing issue for this?

• I have searched the existing issues and there is no existing issue.

What is the feature?

Overview

Implement a system that will create a thread on dm, and allow users to dm back and forth.
As of now, it is fine to not add events to a database, but the methods to update the database should be made.

Ex

async def log_message(...):
   pass

In addition, places where the dispatch system will be called should be noted with comments, and some behavior (like must the event pass) should be handled, if possible.

Once the database exists, we can add the methods for that well.

Commands

Note: all of these commands will need to be configurable to a provided role list or permissions list at a later point in time.

• reply: only usable in a ticket channel
• close: only usable in a ticket channel. By default, only members who have Manage Thread permission
• open: open a thread with a member, by default only usable by members who have manage thread permissions in the modmail_threads channel

Implementation details

• relay messages from dms to thread channel
• relay messages from thread channel to dm
• silent opens. When running the open command, default behavior should be to not actually dm the user, but check if they can
• relays should handle stickers from both ends, and custom emojis.

Would you like to implement this yourself?

Yes, I'd like to implement this

Docs: migrate from mkdocs to sphinx

Description

Sphinx is more supported, and has more features than mkdocs. There is a wider infrastructure than mkdocs, and sphinx can do more build-time injections.

Specifically, sphinx can show a version selector and show docs of specific version for free¹

In order to keep our docs in markdown, we are able to use MyST with Sphinx to minimize the changes required to our documentation pages. If we don't want to maintain markdown docs, it is possible to convert them to reStructured Text and then commit them as rst files.

For themes, there is a community collection of some of the themes visible at https://sphinx-themes.org/. Personally, I'm a fan of the furo theme.

Footnotes

1. Our theme actually does support a version selector, but it is not fully free. ↩

chore[bot launcher]: refactor launch system

Is there an existing issue for this?

• I have searched the existing issues and there is no existing issue.

What is the feature?

Overview

Refactor launch system.

The current launch system involves a bunch of stuff in __main__.py, but that should all be in the bot.run bot method.

In addition, there should be a class method to create a bot with our custom configurations.

Would you like to implement this yourself?

Yes, I'd like to implement this

Issue and Pull request Templates

Look at the Github Docs on how to do this.

Error Handling

Bot needs error handling so the user knows what went wrong. This is also very useful for debugging purposes.

Update to dpy master branch

With threads released on discord, use discord py master branch for sweet slash commands, thread support, and more.

Blocked by #21

Changelog Scripts

Is there an existing issue for this?

• I have searched the existing issues and there is no existing issue.

What is the feature?

Changelogs should be handled by some scripts for this project.

Preferably, all output should be controlled by a jinja2 template, so its easy to modify the program output in the future.
Any needed configuration should be from a toml or yaml configuration file, and not as a file constant.

There's two seperate scripts and one workflow here.

• the compiler, which compiles the fragments into the changelog file
• a generator, which assists with a user creating a fragment for their contribution
• a very simple check workflow, which just checks that a user has added a fragment to the folder,

The compiler script is the most complex by design, whereas the generator script can be as simple or as complex as desired.

Naming scheme

All fragment files should be named like 123.feature.md
123 being the pull request number, and the second part being the kind of change.
If multiple changes were made in a pr, 123.feature.2.md should be supported. The number is mostly irrelevant, but should be used for ordering the changes.

Compiler Script

Configuration should be able to set all of the different categories and their positioning.
The version to build can be gathered from either modmail.__version__ or from [tool.poetry.version] in pyproject.toml
The changelog file itself should be able to be controlled with a jinja2 script.
In addition, there should be a configurable option for what regex or string in the existing changelog file to inject the new underneath.

Generator

The generator is the user-facing script which helps generates a new fragment file. If desired, feel free to use click to help make the UI.
The end goal here to easily make a fragment file. Aside from being able to supply everything in the command with flags, this should also prompt the user for input if it was not provided.

Other thoughts

After thinking about it, a pre-commit script might be cool for checking files in the changes directory are validly named. This is not necessary, but might be a fun addition

Would you like to implement this yourself?

No, someone else can implement it

[Plugins] Not inheriting from PluginCog causes an error which is not about the problem at all

Is there an existing issue for this?

• I have searched the existing issues and there is no existing issue.

Current Behavior

Error which has nothing to do with the root cause, and therefore, easy solution.

Expected Behavior

Steps To Reproduce

Minimally reproductive code:

import logging

from discord.ext import commands
from discord.ext.commands import Context

from modmail.plugin_helpers import ModmailBot, ModmailLogger

log: ModmailLogger = logging.getLogger(__name__)


class Planet(commands.Cog):
    """This is a planet."""

    def __init__(self, bot: ModmailBot):
        self.bot = bot

    @commands.command()
    async def world(self, ctx: Context):
        log.debug("The alien {0} has requested to know what planet they are on.".format(ctx.author))
        await ctx.send("earth")


def setup(bot: ModmailBot):
    bot.add_cog(Planet(bot))

Select your hosting method

local hosting

Anything else?

No response

Remove Dependabot

• Dependabot PRs are really annoying, so remove it! (#86)
• Make a dependabot-like workflow that runs weekly and upgrades all the deps, the generated PR should summarize the changes (version updates) and if possible even like the changelog.

CI: Build to GHCR on push to main

Can be worked by as soon as #13 gets merged!

feat: Documentation framework

Is there an existing issue for this?

• I have searched the existing issues and there is no existing issue.

What is the feature?

Hosting documention.

Should be both current and to be implemented features.

@bast0006, I'm putting you in charge of getting the framework for this out there.

Would you like to implement this yourself?

No, someone else can implement it

[Addons]: Installation system

Overview

Installation system for plugins. Portions of this may be used in the future for other addons, so nearly everything up to when the import is done should be in an addons.py utility file.

The currently supported type of repos are in zip format, using the following structure:

user/repo/Plugins/name/name.py

This gives the advantage to be able to extend the addons api in the future without having to worry about the structure of the repo.

Details

Provided a github or gitlab repo, should parse it to get the specific plugin information, if it exists, from the index.toml file. (I'm open to renaming this file, if someone has a better idea.)

This allows for a user to see what plugins are available in a repo, without installing them. At minimum, this should support github and gitlab repos, given that we can utilize the api to see what is available without downloading. If an index.toml file exists, it should be parsed to get the information. If it does not exist, then we need to get a list of all of the directories in the Plugins folder, which will construct our list of plugins. This does have the side effect of not having any of the metadata for any of the plugins, but I'm of the opinion that an index.toml file is optional and should not be required.

At minimum, the portions that should be in an utils file are:

• checking it contains extensions of this type
• checking it is a github or gitlab repo
• getting the index.toml file

Coverage: Migrate to coveralls?

Description

Codecov is deprecating its uploader. Rather than continue to use codecov, we should shift to coveralls.

However, due to coveralls often having outages, this should be set in the workflow to always exit this step with 0, even if there was a failure.

Its probably possible to do some chaining with echo and stuff, see https://docs.github.com/en/actions/creating-actions/setting-exit-codes-for-actions#about-exit-codes

There also is the underlying question, do we need to have coverage reported at all?

feat: Automatic bumping of version with poetry

Is there an existing issue for this?

• I have searched the existing issues and there is no existing issue.

What is the feature?

Configure a workflow or precommit check or something.

Some way to ensure that with all pull request merges, we follow semantic versioning.

Would you like to implement this yourself?

Yes, I'd like to implement this

feat: Menu Pagination

What is this feature?

We'd like to make a custom paginator for paginating menus, and it should use discord's new button interactions.
As we're on the master branch of discord.py, there is button support, and the docs from discord themselves may be of use as well.

Describe how you'd like this to be implemented

• There should be 5 buttons. Jump to first, back, forward, jump to last, and stop.
• If there is only one page to paginate, all buttons except the stop button should be disabled.
• If there are two pages, then the jump to first and jump to last buttons should be disabled.
• The paginator should be self cleaning, making sure that buttons are removed after a default time.
• This should handle all interactions, and not let any fail, by default.
• • If a user does not have permission to use these pagination buttons, an ephermal message should be sent, rather than letting the interaction fail.
• • There may be cases where it would make more sense to let the interaction fail, so this behavior should have an override.
• If the paginator times out or is stopped, the message should be edited to remove the buttons.
• If an interaction is received that the bot can't handle anymore, the message should be edited to remove the buttons, in order to make sure that the bot won't be spammed by interactions on messages that can't be used anymore.

chore: refactorlogging

Is there an existing issue for this?

• I have searched the existing issues and there is no existing issue.

Current Behavior

The code for logging is terrible. There's double formatters, a bunch of mess, and more.

Expected Behavior

Less code.

Steps To Reproduce

1. Pull the repo
2. Run the bot
3. Logs have a lot of unnecessary code.

Select your hosting method

local hosting

Anything else?

No response