Repository navigation
Conversation
d3aa2f7 to
1edf9cc
Compare
| * </ul> | ||
| * The ban and unban only serves to delete the messages, the user is free to join back afterward. | ||
| */ | ||
| public final class ThisIsScamCommand extends BotCommandAdapter implements MessageContextCommand { |
There was a problem hiding this comment.
(rename the file, ThisIsAgainstRulesCommand)
There was a problem hiding this comment.
Will do it at the end
| Message message = event.getTarget(); | ||
| Optional<TextChannel> modMailChannel = findModMailChannel(event); | ||
| if (modMailChannel.isEmpty()) { | ||
| reportedMessageToTimestamp.invalidate(message.getIdLong()); |
There was a problem hiding this comment.
It's an edge-case: I noticed an issue while doing the tests. I know the handleWasAlreadyReportedMessage() puts the message Id in reportedMessageToTimestamp before the alert is sent to mods, to block duplicate reports. But If the send then fails, the message stay marked as already reported for the cooldown duration. which is 1 day and I keep getting that msg again an again. But with this change, invalidating that entry on failure so the report can be retried once a problem is fixed. It only runs on the failure cases -> the successful alerts are unaffected
There was a problem hiding this comment.
i dont quite follow. can u provide details and maybe screenshots pls, thanks
There was a problem hiding this comment.
Background: handleWasAlreadyReportedMessage() stores the message ID in reportedMessageToTimestamp before the alert is posted to the mod channel, to block duplicate reports. That entry lives for 1 day. (The per-user cooldown is a separate 1 minute timer.)
The problem: if posting the alert then fails, the entry stays. Nobody can report that message again for 24h, even though the mods never saw it.
How to reproduce (I renamed the modmail channel so the pattern doesn’t match, but denying the bot “Send Messages” there fails the same way):
-
Rename the modmail channel so the lookup fails, then report a message.
👉 User gets “Sorry, there was an issue forwarding your report…” and the log says “Cannot find the designated mod mail channel…” -
Rename the channel back and report the same message again (after the 1 minute cooldown).
Without the invalidate calls: the second report is rejected with “This message was already reported.” although no alert was ever posted.
With the invalidate calls: the failure paths remove the entry, so the second report goes through and the mods get the alert.
Successful reports are unaffected, since invalidate only runs in the 2 failure branches (mod channel not found, and sending the alert failed).
It’s a small robustness fix, but if you’d prefer to keep it out of this PR I’m happy to split it into a separate one!
| private static void showResult(InteractionHook hook, List<MessageEmbed> alertEmbeds, | ||
| String text, Color color) { | ||
| hook.editOriginalEmbeds(withResult(alertEmbeds, text, color)).queue(); |
There was a problem hiding this comment.
mh, i dont think this helps readability. remove this method please
Zabuzard
changed the title
ThisIsAgainstRulesCommand (Scam and Job-Ad) (formerly ThisIsScam, only Scam)
Zabuzard
added
enhance command
|
What
Replaces the
this-is-scammessage context command with a more genericthis-is-against-rulescommand (ThisIsAgainstRulesCommand).When a user reports a message, mods now get three buttons instead of Yes/No:
WARN), then ban + unban to delete the recent messages.In both Scam and Job-Ad the ban/unban only serves to delete the message history,
the user can join back right away.