-
-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run AutoMod-blocked messages through autowarn filters #217
Conversation
# Conflicts: # Events/MessageEvent.cs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, just one nitpick in the comments.
re: wording, I think it's best to be generic instead of situational with these.
"Play around with lots of emoji" can stay as-is.
then:
- msgOut = await message.Channel.SendMessageAsync($"{Program.cfgjson.Emoji.Information} {message.Author.Mention} Your message was automatically deleted for mass emoji.");
+ msgOut = await message.Channel.SendMessageAsync($"{Program.cfgjson.Emoji.Information} {message.Author.Mention} Your message contained too many emoji.");
- string output = $"{Program.cfgjson.Emoji.Information} {message.Author.Mention}, your message was deleted for containing too many lines.\n" +
+ string output = $"{Program.cfgjson.Emoji.Information} {message.Author.Mention}, your message contained too many lines.\n" +
but also, can we please make the too many lines not offer the chance to show the full message, specifically for automod checks? It runs after other checks for a similar reason, which is to not act as an automod bypass opportunity.
Done! Good thinking with the automod bypass catch, that obviously didn't occur to me 😅 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, merge when ready. The bug with some automod events not working correctly doesn't have any catastrophic consequences and doesn't appear to be the fault of this code.
This PR closes #209.
Runs messages that are blocked by AutoMod through our typical autowarn filters. This means users will be automatically warned for messages that would typically trip Cliptok's filters, even if AutoMod blocks the message from being sent first (currently this results in Cliptok not even seeing the message). This includes filters, like unapproved invites, mass emoji, scam checks, etc., but not 'passive' checks like user tracking*, passive list tracking, etc.
*Blocked messages will still end up in user-tracking threads in some way. It looks like this is just a blank embed pointing to the #investigations AutoMod message. This is because that message causes a Message Create event to be fired, and that is what makes it through to the tracking thread! I was initially not sure what to do about this, but I decided to leave it because I think it fits, considering how the point of the thread is to track all of the messages sent by a user.
AutoMod events don't give us a
DiscordMessage
, so this was a little awkward to do. I chose to create a fakeMockDiscordMessage
with the properties from the AutoMod event, and adjusted things like the message handler to accept that instead ofDiscordMessage
(there are now two overloads—one that takes aMockDiscordMessage
and does the handling on that, and one that takes aDiscordMessage
, throws its data into aMockDiscordMessage
, and passes that to the other overload—this way there's no trouble when trying to use a regularDiscordMessage
. I also did this for theDeleteAndWarnAsync
andMessageLink
methods).One thing I'm not sure about is the phrasing for when a user is pardoned the first time they send a message containing too many emoji or lines. For example, you can see here:
Cliptok/Events/MessageEvent.cs
Lines 488 to 491 in dff0e2a
Cliptok/Events/MessageEvent.cs
Lines 623 to 627 in dff0e2a