[firasrg]

What

Replaces the this-is-scam message context command with a more generic
this-is-against-rules command (ThisIsAgainstRulesCommand).

When a user reports a message, mods now get three buttons instead of Yes/No:

Button	What happens
Scam	Same flow as before: DM, quarantine, then ban + unban to delete the recent messages.
Job-Ad	DM, warning recorded (WARN), then ban + unban to delete the recent messages.
Dismiss	Nothing happens, the alert is closed.

In both Scam and Job-Ad the ban/unban only serves to delete the message history,
the user can join back right away.

[Zabuzard]

(rename the file, ThisIsAgainstRulesCommand)

[firasrg]

Will do it at the end

[Zabuzard]

why that logic change?

[firasrg]

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

[Zabuzard]

i dont quite follow. can u provide details and maybe screenshots pls, thanks

[firasrg]

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):

1. 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…”

2. 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!

[firasrg]

[Zabuzard]

Remove your cache invalidate lines. Move the highlighted section where we are searching for the channel one section above, so it happens BEFORE we put the thing into the cache to begin with (it happens inside the handleWasAlreadyReportedMessage method). So if it fails to find the channel, we never put the entry into the cache to begin with, then we also have no need to invalidate anything.

For the second one, when the sending itself fails (despite all the previous checks), we simply dont handle the case. No invalidation, whatsoever. At this point the message is considered reported - even if the actual sending failed (for example due to discord api or network hicups).

[firasrg]

Done the changes like you said:

@Override
public void onMessageContext(MessageContextInteractionEvent event) {
    if (handleIsOnCooldown(event)) { return; }
    
    Optional<TextChannel> modChannel = findModChannel(event);
    if (modChannel.isEmpty()) {
        event.reply(FAILED_MESSAGE).setEphemeral(true).queue();
        return;
    }
    
    if (handleWasAlreadyReportedMessage(event)) { return; }
    
    Message message = event.getTarget();
    reportToMods(message, modChannel.orElseThrow()).mapToResult().map(result -> {
        if (result.isFailure()) {
            logger.warn("Unable to forward a report to the mod mail channel.",
                    result.getFailure());
            return FAILED_MESSAGE;
        }
        return "Thank you for your report, a moderator will take care of it 👍";
    }).flatMap(response -> event.reply(response).setEphemeral(true)).queue();
}

Result (it's worst i think):

thisisscam-issue-2.1.mp4

[Zabuzard]

thats not what i expected this code to do. it shouldnt have put it into the cache bc we returned before reaching the line that would add it. ill checkout ur code and figure out why its behaving like that.

[Zabuzard]

please push the changes so i can test it easier, thanks

[firasrg]

Done

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud