Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Moderation cog cleanup #462
This is not extensively tested. I am hoping for others (i.e. the reviewers) to help out in this regard considering the importance of these cogs.
This aims to reduce redundancy and code density in the moderation cog.
The moderation cog was split in two:
To facilitate this move, custom category support was added to the help command. This allows the
Just to define some terms:
Manual tests for
The infraction search and edit commands should be separated from the moderation cog and put into a new cog. Should both the moderation and the new cog be moved into a moderation-related subpackage (moglog could go in there too)? If so, what would the package be named and what would the modules (yes, I mean the modules, not the cog classes) be named? Would the contents of
I can understand the logic behind splitting the moderation cog up to make it more manageable in the files, but having to put infr search and edit into an entirely different command category (user-facing) doesn't make much sense to me. Infraction management fits perfectly under the category of "Moderation", so I'm not sure I'm a fan.
* Move respect_role_hierarchy to the decorators modules * Get the command name from the context instead of an argument
These adjustments make it easier to call the function using values directly from the infraction object as arguments. * Set actual default values inside the function if values are None * Accept only a string for expires_at
* Rename the UserTypes alias to UserConverter * Create a new non-converter alias similar to UserConverter which has Object instead of the proxy_user converter in the Union. * Use the new alias in the utility functions instead of just a Union of a Member and User.
* Rename to apply_infraction * Make messages more generic to simplify implementation * Send the confirmation message inside the function; return nothing
* Rename UserConverter to MemberConverter * Rename UserObject to MemberObject * Move MemberObject to moderation utils module * Move proxy_user to moderation utils module
Commands defer to these functions, configuring them to be temporary and/or shadow infractions by passing some kwargs. This reduces code redundancy.
* Rename Infractions cog to ModManagement * Rename Moderation cog to Infractions * Rename infractions.py to management.py * Rename moderation.py to infractions.py * Move moderation utils to sub-package and rename to utils.py * Move Modlog, Infractions, and ModManagement to sub-package * Use sub-package as an extension that loads aforementioned cogs
* Read names from JSON instead of a module * Move get_nick function inside the Superstarify cog * Load Superstarify cog through the moderation extension * Define __all__ for moderation module
I'm working on resolving the conflict caused by #486. I want to just replace all the redundant infraction deactivation code it brings with a call to
Does anyone have ideas for clean and non-redundant way to handle deactivating the infraction?
For the four infractions types below, the
One option is to split this method that does two things, removing the role from the member and requesting the API to mark an entry in the database as inactive, into two methods that do one thing, optionally having the
We would get the most flexibility if we were to add a third method, a wrapper that calls both, and don't have the
If the mute was split, it'd be something like this:
async def pardon_mute(self, ctx: Context, user: Member): self.mod_log.ignore(Event.member_update, user.id) await user.remove_roles(self._muted_role, reason=reason) # DM the user about the expiration. notified = await utils.notify_pardon( user=user, title="You have been unmuted.", content="You may now send messages in the server.", icon_url=utils.INFRACTION_ICONS["mute"] ) return notified
However, splitting the function won't solve the issue of the DM not being sent on failure. As I said, normally we'd want the DM to not send if removing the role failed. Therefore, in this case, a try-except would need to be around the
I would prefer to not have such a parameter but it seems like it may be the better option given how convoluted and intraconnected this function already is.
I don't think I understand what you mean. From the fix you were referencing, I was under the impression we were talking about calling
If so, that means the user does not have the mute role, since they just joined the server. By splitting up the
I think you mean was not a member, but that make sense so I agree. Now I am wondering if we even want to show the expiration as failed in the mod log when the user already doesn't have the muted role or they don't have an active ban. Thinking about it now, it's actually technically still a success in the sense that they indeed are no longer affected by the infraction, which was the goal of the function.
If that is changed to not show as a failure along with not caring about DMing in this situation, then I can once again simply use