Red-discordbot: Mod cog is becoming huge (and essential)

[Twentysix26]

The problem

The mod cog is becoming huge and covers too many functionalities.
It contains features that do not belong there and, worse, core functions that shouldn't be possible to deactivate.

It its current state it contains:

• Moderation commands
• A full fledged mod-log (with a pending PR that turns it into an API)
• Some logging features (names, nicknames, etc)
• Filters / spam prevention
• Global blacklist / whitelist
• Commands to set server's admin role and mod role. While of course related to moderation, these roles are used by all cogs and the commands used to set them shouldn't be stuck in mod.py
• Settings such as autodeletion of commands

And I'm probably forgetting something.

This isn't good, the user should be free to disable the mod cog without losing core functionalities. At the moment, disabling mod.py means losing the admin / mod role checks that all cogs use.
This also limits customizability. If you want auto command deletion it means that you're also getting everything else.

Proposed solution

Let's start with moving some functions out. The first ones to go are the ones listed above that do not belong in mod.py at all.
Moving the modlog to its own cog might be preferable too, although not strictly necessary, as I expect most people who use it also use our moderation commands.
Thoughts? Design suggestions?

Status:

• [x] Moved whitelist commands to owner cog
• [x] Moved modrole / adminrole commands to owner cog, under [p]set

[palmtree5]

If modlog is to be moved to its own cog, then mod needs to make sure it's loaded. Also I'll have to update my PR accordingly

[palmtree5]

I'd say the settings, the mod/admin role setting commands, and the global blacklist/whitelist should be moved out of mod (probably to owner)

[Twentysix26]

@palmtree5 That's the plan, already in the PR

[palmtree5]

Got it. On the other stuff, I'm not sure the logging features necessarily belong in mod. I'd say filters/spam prevention stuff could stay where it is though

[palmtree5]

Thinking about the idea of separating modlog. On loading mod (or any other cog that would use the modlog), we'd need to ensure the modlog cog is loaded or else fail to load and tell the user why. And if someone tries to unload the modlog, we need to handle unloading any cogs that depend on it as well (which means probably maintaining a manual registry of what cogs depend on it as a settings file for modlog)

[palmtree5]

I'm thinking server/channel ignore/unignore could also be moved elsewhere

[palmtree5]

Ok, so despite my PR (#709) moving ignore and unignore to Owner, maybe it's time to consider throwing in another default cog that is always loaded and cannot be unloaded unless it's a reload (core.py). This would contain things that should be available all the time but that perhaps don't fit in the theme of owner (for example: ignore and unignore). Maybe there's other commands that could go in this hypothetical new cog too

[palmtree5]

Another candidate for core.py: Cog-Creators/Cog-Board/issues/25

Since it's likely the checks would be done in red.py

Actually, maybe the per-server modrole/adminrole/prefix settings could also be moved there as well

If cogs ever become per-server, the server-specific commands for turning cogs on and off could probably go in core.py as well

[tekulvw]

@palmtree5 @Twentysix26 do we need this anymore?

[Twentysix26]

I don't have plans for further debloating

[palmtree5]

I've been splitting things between files in the rewrite (though they're still in cogs/mod) and then loading each using bot.add_cog in the package's __init__.py

[tekulvw]

Okay so the decisions have been made and this issue can be closed?

[Twentysix26]

👌