Skip to content
This repository was archived by the owner on Jul 22, 2025. It is now read-only.

Conversation

@SamSaffron
Copy link
Member

Previous to this change we could flag, but there was no way
to hide content.

We had the option to hide topics, but this is not desirable for
a spam reply.

New option allows triage to hide a post if it is a reply, if the
post happens to be the first post on the topic, the topic will
be hidden.

Previous to this change we could flag, but there was no way
to hide content.

We had the option to hide topics, but this is not desirable for
a spam reply.

New option allows triage to hide a post if it is a reply, if the
post happens to be the first post on the topic, the topic will
be hidden.
# as it is mainly used for spam where notification
# is not needed.
# we will need another flag if we want to notify
if hide_post
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like you could lean on post.hide! in core here https://github.com/discourse/discourse/blob/c446caa6e9f68be24bdc3d0ff0b33e0ddc2130c6/app/models/post.rb#L604-L604 since it's doing the same thing the code does here, and give it PostActionType.types[:spam] as the post_action_type_id. I think the only thing you would need to do is your additional topic visibility update.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also generally I am not sure this with the flag_post/needs_review part above is quite the correct way to go, seems like going through the PostActionCreator and indicating that it's for spam :

PostActionCreator.new(
  Discourse.system_user,
  post,
  PostActionType.types[:spam],
  message: message,
  queue_for_review: true,
).perform

This auto-hides if necessary and also does the needs_review! on the flagged post. If we did this the hide_topic and hide_post options might not be necessary for the automation.

It feels like we are not relying on the review queue logic to properly mark this as spam, and since this is the case if you mark the reviewable invalid / disagree the post might not get unhidden as you already indicated, and there is no testing for this.

The review queue logic is super hard to follow though so I understand the appeal of doing it in a more basic way here, I just think it may cause other problems doing it this way. This may solve the customer's immediate problem but I am not sure it's maintanable. Maybe we can do some further digging first and try out PostActionCreator before merging this?

Copy link
Contributor

@martin-brennan martin-brennan Oct 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might also be worth having 2 options:

  1. Send to review - Leave this as is, just ask for post approval
  2. Mark as spam - Follow the spam flow with PostActionCreator, which would also do the hiding

And getting rid of hide_post and hide_topic options

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

its tricky cause hide_topic is used for automations that do not flag, we can not get rid of it. But I can try to see if I can get PostActionCreator going and allow people to select "send to review/mark as spam/don't involve review" ... its so complicated :(

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth mentioning that back on the old toxicity / nsfw days we used PostActionCreator and had problems because people don't always want the users to be aware that they were flagged / auto-hidden, which happens on both public topics and PMs.

This is the main reason we now only send to the queue without all the usual flag adjacent side effects. But that also means that if people now want it, it needs to be an option much like what @martin-brennan described.


post.update!(hidden: true, hidden_at: Time.zone.now, hidden_reason_id: reason)

post.topic.update!(visible: false) if post.post_number == 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SamSaffron
Copy link
Member Author

@martin-brennan I made the change you recommended. This does come with some "by design" compromises.

  1. Akismet ... deletes, this hides. So anonymous will see this noise, which is not ideal: (this is a core problem anyway...)

image

  1. By design, we now will send emails to spammers, meaning "we just hid your post" ... this is probably undesirable (and undesirable for all spam anyway) why waste money on them?

  2. Also by design, "system" is flagging, we probably want to shift it so "Discourse AI" is flagging.

Except for that this works OK and the issues remaining are core issues.

Copy link
Contributor

@martin-brennan martin-brennan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @SamSaffron I really appreciate it. 🤗 It's definitely still not ideal but at least we are in "known review / flagging system craziness" territory now. I think the new "flag type" option here for the AI automation is a great move too.

It's going to be a long, long uphill slog to improve the review queue and flagging system, and I do agree with you (and Falco) that AI will be an important part of this, especially for spam detection since Akismet is just dropping the ball these days, and NSFW/toxicity and so on detection. We really need a better experience for moderators to combat this new world of AI-generated spam with more advanced AI-detection and moderation tools. I just don't think our system makes it easy or pleasant enough for our admins and moderators to spend time in the review queue, and Hugh is finding this a lot too.

For this point:

Also by design, "system" is flagging, we probably want to shift it so "Discourse AI" is flagging.

Not sure how painful/desirable this is, maybe AI needs its own "system user" for these cases? Like Discourse.ai_assistant_user or something for these cases, might make it a bit more personalised and generally useful for the plugin. Not something we need here, just a thought.

@SamSaffron SamSaffron merged commit c294b6d into main Oct 4, 2024
5 checks passed
@SamSaffron SamSaffron deleted the improve-triage branch October 4, 2024 06:11
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants