#How to effectively implement the job post report ?

62 messages · Page 1 of 1 (latest)

rocky ledge
#

In the context of starting the implementation of reporting job-ads, (that are against the server rules), I’d like to fully understand the existing scam report action implemented in TJ Bot (check attachment)

As discussed in #tjbot-discussion message , I must understand how the current scam-reporting flow works so I can implement a similar feature for job-ad reports, but without introducing a separate action (because there are no more free slots) peepo_sad_2 .

What I’m considering is refactoring the current “This is a scam” implementation into a more generic reporting feature that can make the action handles both scam and job-ad.

There is a suggestion, that consists of, when there is a report, the bot sends a msg to mods and renders 2 buttons so they can choose what to do, but i don't really know what would those 2 buttons mean exactly, i invite @mighty cedar to explain it, thanks.

To sum up:

  • What are the local requirements to test the action "this is scam"?
  • How to report both scam and job-ad as one (ui/ux)?
  • Is this feature supposed to be auditable (caught by metrics listener?)?
    Thanks
tribal grailBOT
#

<@&987246924425994290> please have a look, thanks.

rocky ledge
#

How to effectively implement the job-ad report ?

golden steeple
mighty cedar
#

instead of only this-is-scam -> "is this scam?" yes/no

#

the job-ad action would then delete the message and warn the user

#

potentially also deleting more than just one message in case of shotgun job-ad spam

#

but thats advanced

#

while the scam action bans->unbans->quarantines the user

#

we can also go with ban->unban->warn for the job-ad, i wouldnt mind

#

that would solve the message auto-deletion

#

and in the future we could add even more quick-action buttons for this-is-against-rules

#

but now its scam and job-ad

wild summit
#

why ban -> unban? why not: ban

mighty cedar
#

bc scammers deserve to get back into their account -> quarantine
and job-ad often dont know about the rules and typically stop once being told once -> warn

#

we can also add more quick-action buttons like ban/warn to it (second row) but thats for anothe riteration as that would require doing the ban message etc in a modal instead of slash commands

#

also, ban/unban implicitly kicks from the server. often people who are bots or similar just dont even join back

#

so its effective enough

#

i havent thought it fully through it but those are the thoughts at the moment

#

the main point is to turn this-is-scam into a more general thing and mods then have quick action buttons that would represent their usual flow in that situation

#

so they can just click click instead of typing slash commands and whatnot

rocky ledge
#

I see thanks.

Update for my questions:

  • What are the local requirements to test the action "this is scam"?
  • How to report both scam and job-ad as one (ui/ux)?
  • Is this feature supposed to be auditable (caught by metrics listener?)?
#

i assume i should have a second discord account to test this

#

i wonder if Discord has some feature to use temporary accounts just for tests

mighty cedar
rocky ledge
#

got it

rocky ledge
#

guys, if the job-ad poster is warned, but keeps doing same thing again

#

do we change the behavior of the bot ?

#

like from warning to ban?

#

(could be advanced for another issue)

mighty cedar
#

no

#

focus. do what has been explained

#

we can do more later

rocky ledge
#

Alright. Im counting to rename the class ThisIsScamCommand, since now, it handles more than Scam

#

is that ok ?

#

hmm i'm thinking about making 3 classes

#
  • change the existing one into a logic container only for scam messages
  • create another class for the job-ad messages
  • create a container of the 2 other classes representing the command
#

what do you think ?

mighty cedar
#

no, stay with the current class for now. rename it and add a second flow for it that would handle the other button

rocky ledge
mighty cedar
#

the changes happen below, when one of the buttons is clicked

#

that has to be adjusted accordingly

#

into title "Potentially problematic message", buttons "Scam", "Job-Ad", "Dismiss"

rocky ledge
#

got it

#

another question: there is a 'ReportCommand' that lets users report messages. Today If I were to introduce a new general report message command class, it might conflict with the existing one

#

so do I delete that one , or do I put the work inside of it?

mighty cedar
#

report is fine as is

#

it has a different use case

rocky ledge
#

i know but that different usecase can be added to this unified class

#

by just adding a button for it

mighty cedar
#

not today

#

report is for the user to add context. this-is-against-rules is without user provided context

#

we dont want to merge that, that would make UX for the user worse

rocky ledge
mighty cedar
#

we can think about killing /report and then renaming this-is-against-rules to it. but that will be another step, not now

#

focus and start implementing

rocky ledge
#

started on it already.. im gonna need some more time

#

i'll continue tomorrow. Meanwhile, any ideas or thoughts are welcome

rocky ledge
#

BACK

#

so im currently progressing with the work

#

if id change the name of the command

#

i mean this:

private static final String COMMAND_NAME = "this-is-scam";
#

does that hurt the metrics or previous uses of it?

mighty cedar
#

dont worry

#

rename it

rocky ledge
#

got it, im counting to create some records and enums

#

do I put them in separate files ?

mighty cedar
#

what?

rocky ledge
#

i made :

public enum ReportAction {
    SCAM,
    JOB_AD,
    DISMISS
}
tribal grailBOT
mighty cedar
#

i dont see why u would need such an enum. but if, put it in the file, locally

#

or do u need it elsewhere

rocky ledge
#

it's just for the class of the command

mighty cedar
#

i dont see why u would need it. but u know how to design code

rocky ledge
#

got it

mighty cedar
#

put it as close to where its used. ideally in the file, private. unless its needed outside. package private. worst case public... depending on who uses it and where

rocky ledge
#

got it

#

there is something here for the job-ad treatment

#

in the scammer case, the user gets deleted along with their messages thanks to the easy function

private RestAction<Void> deleteMessagesByBanAndUnban(Guild guild, User target) {
    return guild.ban(target, 1, TimeUnit.DAYS)
        .reason(ACTION_REASON)
        .flatMap(_ -> guild.unban(target).reason(ACTION_REASON));
}
tribal grailBOT
rocky ledge
#

but for the job-ad, what we do here ? Thinkfused

mighty cedar
#

i described this above already

#

instead of quarantine + ban + unban we do warn + ban + unban

rocky ledge
#

u mean we keep their messages?

#

i know we would warn

#

but the messages are the point

#

we let the bot keep them ?

mighty cedar
#

no`?

#

i literally just said

#

warn + ban + unban

#

the ban+unban is to get rid of the messages

#

just like with the scam

rocky ledge
#

ah

#

i thought u mean we warn first, if they continue we ban

mighty cedar
#

no, we warn, then ban, then unban

#

and for scam we quarantine, ban, then unban

rocky ledge
#

yea

#

clear

rocky ledge
#

the concerned channel by reports is called modmail right ?

mighty cedar
#

its config based

#

use the same as this-is-scam used

rocky ledge
#

i know but something looks weird here:

private Optional<TextChannel> findModMailChannel(MessageContextInteractionEvent event) {
    Guild guild = Objects.requireNonNull(event.getGuild());
    Optional<TextChannel> modMailChannel = Guilds.findTextChannel(guild, isModMailChannel);
    if (modMailChannel.isEmpty()) {
        logger.warn(
                "Cannot find the designated mod audit log channel in guild '{}' with the pattern '{}'",
                guild.getId(), config.getModAuditLogChannelPattern());
    }
    return modMailChannel;
}
tribal grailBOT
rocky ledge
#

that config.getModAuditLogChannelPattern() should be config.getModMailChannelPattern()

#

especially the method's name indicates to the modmail channel

#

it's confusing

#

on top of the class there is a predicate isModMailChannel and not isModAuditLogChannel

#

it sounded like there are 2 channels

#

look here : private MessageCreateAction reportToMods(Message message, TextChannel auditChannel) {..}

#

can i change these "auditChannel" nouns to simply "modMailChannel" ?

#

i'll do it

mighty cedar
#

there are two channels

#

modmail and mod audit log

#

the code is correct as is

#

dont change stuff

#

play with the existing this-is-scam command in ur test server first so u understand how it works and where is what

#

then ull understand

rocky ledge
#

done that first

mighty cedar
#

so, then u have seen that there are two channels

#

one for modmail and one for all audit logs

rocky ledge
#

but when i tested the command

mighty cedar
#

two channels for different purposes

rocky ledge
#

the only channel that got the msg was modmail

#

following the code the audit log channel is alternative right ?

mighty cedar
#

this is not sth anyone knows adhoc. we have to dig code

rocky ledge
#
@Override
public void onMessageContext(MessageContextInteractionEvent event) {
  // some code

    Optional<TextChannel> modAuditLog = findModMailChannel(event);

  // some code
}
tribal grailBOT
rocky ledge
#

this part confuses me

#

the method says it's a modmail channel, but the variable says it's another channel

mighty cedar
#

gimme a second

#

there:

#

it was originally mod audit log

#

then was changed to modmail channel by suraj kumar

#

and that PR was dirty

#

only changed half of the variable names and comments in the code

#

its supposed to be called modmail everywhere in this class

#

etc

#

rename it everywhere in this class

#

modmail. not mod audit

rocky ledge
#

Hmm, ok ok

#

so that means i should remove log audit channel

mighty cedar
#

no. the channel is used by other stuff. dont kill it

rocky ledge
#

i mean remove its use/call in this class

mighty cedar
#

ThisIsScamCommand uses modmail channel. but the renaming in the class was only half way done

#

its just variable names and comments

#

the actual thing being used is the modmail channel

rocky ledge
#

ok so i should rename every logAuditChannel thing into ModMailChannel right ?

mighty cedar
#

every mention of "audit channel" or whatever in ThisIsScamCommand is supposed to be called modmail

rocky ledge
mighty cedar
#

or i dont know, call it just mod channel if u want to reduce "text dependencies" like that

#

then it doesnt need to be touched anymore if we rename channels again

rocky ledge
#

alright so this method is the first one getting significant changes here

@Override
public void onButtonClick(ButtonInteractionEvent event, List<String> args) {
    Member moderator = Objects.requireNonNull(event.getMember());
    List<MessageEmbed> alertEmbeds = new ArrayList<>(event.getMessage().getEmbeds());
    AlertAction action = AlertAction.valueOf(args.get(2));

    if (action == AlertAction.DISMISS) {
        String text = "Dismissed by %s, no action executed.".formatted(moderator.getAsMention());
        event.editMessageEmbeds(withResult(alertEmbeds, text, Color.RED))
            .setComponents()
            .queue();
        return;
    }
    // TODO: handle report action
}
tribal grailBOT
mighty cedar
#

yes. bc it can now have 3 instead of 2 buttons

#

so it needs to check which button was pressed and forward to the right action

rocky ledge
#

alright and i check first the dismiss

#

in the prev version it checks on !isScam

mighty cedar
#

dismiss can stay as is i think. it should just not do anything

#

remove/disable the buttons or sth i guess

#

but no harm done to the user

#

and the yes button becomes the scam button and otherwise stays as-is as well

#

and then u simply add a third button to it based on the scam button

#

which is then the job-ad button

rocky ledge
#

which color for job-ad button

#

BTW something seems wrong in the cache

#

when i shutdown the app or remove a report msg from the modmail, then i want to report same msg again, i get "this msg was reported already"

#

ah i see, there are no invalidate to cache when failed

#

but why ?

#

nevermind

#

alright here we go

#

the new name is "RuleViolationAlertCommand"

#

not sure if those colors are good for buttons

viral heron
#

try all yellow button

rocky ledge
#

it doesn't exist apparently

#

even that ButtonStyle doesn't have it

viral heron
#

weird, no way to put the color you want

#

a well, too bad

rocky ledge
#

id keep like in my screenshot

mighty cedar
#

they are both danger buttons

rocky ledge
#

oh k

mighty cedar
#

we will use the blue color for the second row buttons in a next iteration

#

(ban, warn, ...)

#

or wait

#

wasnt it green before?

#

and red for the NO/dismiss?

#

please check the original this-is-scam

#

we want to preserve the color coding

#

else we harm ux

rocky ledge
#

the Yes button was green

#

but that doesn't make sense to me

mighty cedar
#

it makes sense to me though

#

please keep it that way

#

green for the active actions, red for the abort action

rocky ledge
#

2 green buttons for a dangerous action ?

mighty cedar
#

yes, thanks

#

u need to view this from the perspective of the mod, who is the user for this

#

green is the active action. the one that moves the flow forward

rocky ledge
mighty cedar
#

the primary action

#

dismiss red

#

just like it was before

#

also, not "Rule Violation Alert". please stick to the UX i gave u earlier

rocky ledge
#

BTW ive got something funny here

rocky ledge
#

u didn't say anything about title shown there

mighty cedar
#

i did tell u how to name it

rocky ledge
#

ah i didn't read that sorr

mighty cedar
#

but ok, i like Rule Violation as well

#

go with Rule Violation

#

🙂

rocky ledge
#

🙃

#

ok

#

ive found something funny, the user can report their own msg !

#

was that on purpose or escaped as an edge-case??

mighty cedar
#

not necessary to handle this situation

rocky ledge
#

but a user can do mistakes

#

like they select a wrong msg

mighty cedar
#

it doesnt matter

rocky ledge
#

ok

mighty cedar
#

i would rather want to change the cooldown

#

thats actual friction im running into

#

but focus, this PR is about job-ad

rocky ledge
#

we set it as env variable ?

mighty cedar
#

we can do other stuff in another round

rocky ledge
mighty cedar
rocky ledge
#

feels like im doing CR to your old work LUL

mighty cedar
#

the cooldown should for example allow reporting maybe up to 5 messages before triggering

#

but its for another round, not now

#

a similar problem exists with /report which already starts counting the cooldown even before the report is submitted. /report, then aborting the flow and trying /report again will trigger the cooldown. but that just as a note

rocky ledge
#

got it

#

alright, i'm now in the core logic here

#
private void judgement(ButtonInteractionEvent event, AlertAction action, Guild guild, Member moderator, Member target, List<MessageEmbed> alertEmbeds) {

    Member bot = guild.getSelfMember();

    boolean canJudge;
    if (action == AlertAction.SCAM) {
        Role quarantinedRole = ModerationUtils.getQuarantinedRole(guild, config).orElse(null);
        canJudge = ModerationUtils.handleRoleChangeChecks(quarantinedRole, "quarantine", target, bot, moderator, guild, SCAM_REASON, event);
    } else {
        canJudge = ModerationUtils.handleCanInteractWithTarget("ban", bot, moderator, target, event);
    }

    canJudge = canJudge && ModerationUtils.handleHasBotPermissions("ban", Permission.BAN_MEMBERS, bot, guild, event);

    if (!canJudge) {
        logger.warn("Unable to execute judgement");
        return;
    }
    
    // TODO: execute...
}
tribal grailBOT
rocky ledge
#

ive made this helper function

#

it's still in dev

#

it starts with some checks

#

ive used the handleCanInteractWithTarget() in case the case isn't scam

#

im not sure if that's the right choice

#

but it's working

mighty cedar
#

looks weird to me but its hard to say anything really with random snippets like that

#

make a PR when ur ready then u get a proper CR

rocky ledge
#

yea ok

mighty cedar
#

the only tip i can give for now is to not reinvent the wheel. keep the code close to what it was

#

there is no need to change much or "improve everything" or "restructure the code"

#

it was fine as is

rocky ledge
#

yea but here i dnt have quarantine for the job-ad

#

the changes are mostly in these methods

#

onButtonClick

mighty cedar
#

like, there probably was some handle method that was called for the YES button (for scam)

#

and that method can stay as is, no changes needed

#

and the for job-ad button u can probably just copy that method and adjust it a bit

#

so it does warn instead of quarantine

#

etc

#

and thats it

#

no need to restructure everything

#

or whatever

#

thats all i can say for now without really seeing what u do

rocky ledge
#

im not talking about the execution of the actions here,

mighty cedar
#

the rest comes at CR-time.

rocky ledge
#

ok ok

#

then i think i'll close this help thread for now

#

ive got much information and many tips

mighty cedar
#

like, why ar eu doing this judgement of rules now

#

was this done before already or not

#

it was fine as it was

#

no need to add extras now

#

focus

#

thats what i mean

rocky ledge
#

aah the handleConfirmedScam()

#

ok then i ll make it like this one

mighty cedar
#

if ur going off track ull get a big CR "change everything". so ideally u stay close to whats being layed out for this

rocky ledge
#

im doing some brute force actually

#

im keeping comparing with previous version

#

im doing rollbacks when i see something useless

#

im trying to keep only interesting parts

mighty cedar
#

what ur saying gives me "wtf is he doing" vibes. but ok, go ahead. ill judge when i see a PR

rocky ledge
#

alright