Feedback on the new Review Queue

I’d like to use a webhook to remove spammers from our central database when I delete them in the review queue, but no event is triggered when I set up my webhook like this. Is it supposed to, or do I misunderstand the ‘… and when its status is updated’ part?

1 Like

Does a “user delete” webhook get triggered?

3 Likes

It does. Unfortunately it’s not passing a deletion and I’d like to specifically only act when a user has been deleted+IP blocked.

1 Like

I’d like to request the ability to auto-hide images by default, specifically for flagged posts by TL0 users. While there’s the need to see inappropriate images and act on them per each community’s standards, it would be helpful to hide images for those in office settings or working from home with kids around (as I often am).

6 Likes

The API for “bypassing” requiring review queue scoring is still not sufficient over a period of time as the score is recalculated periodically. If the queue is not handled at the time of the reviewable being created, the “forced” item can disappear off of high-filtered lists before moderators can review those items.

Perhaps we should have force-review a boolean on the reviewable that is joined to the score query here.

5 Likes

TL0 user’s images are blurred by default. This can be disabled via the blur_tl0_flagged_posts_media setting.

This is also done. When the force_review flag is set to true, pending reviewables will appear in the queue even if they don’t meet the minimum visibility threshold score.

8 Likes

@Roman_Rizzi - Sorry I haven’t got back to you about this yet. If it is still potentially helpful, I’ve got the logs and pulled out some records (cleansed of identifying info). Running currently on 2.6.0beta3. All the integer out of range errors seem to be for the same type of records.

2020-11-26 06:02:13.009 UTC [25408] discourse@discourse ERROR:  integer out of range
2020-11-26 06:02:13.009 UTC [25408] discourse@discourse STATEMENT:  INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17769856,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.008758', '2020-11-26 06:02:13.008758', 1333533, 4) RETURNING "id"
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse ERROR:  integer out of range
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse STATEMENT:  INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17725230,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.037676', '2020-11-26 06:02:13.037676', 1313715, 38) RETURNING "id"
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse ERROR:  integer out of range
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse STATEMENT:  INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17713480,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.051222', '2020-11-26 06:02:13.051222', 1314869, 237) RETURNING "id"
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse ERROR:  integer out of range
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse STATEMENT:  INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 180552, '{"topic_title":"{private info removed}","original_post_id":17713479,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.148264', '2020-11-26 06:02:13.148264', 1313773, 48) RETURNING "id"
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse ERROR:  integer out of range
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse STATEMENT:  INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 46891, '{"topic_title":"{private info removed}","original_post_id":17760644,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.168959', '2020-11-26 06:02:13.168959', 1328670, 25) RETURNING "id"
1 Like

It could also be nice to have a way to see a list of reviewables that have been reviewed, filtered by the moderator that handled flags - “assigned to” as a filter when looking in past handled flags seems to be very similar semantically to someone looking for a “handled by” filter but it is different.

Should “assigned to” with resolved flags/reviewables query who handled flags, or can this be a separate filter?

4 Likes

I think this is a great suggestion @Roman_Rizzi - can you add to your list?

5 Likes

I’m using a webhook and the API to put new topics in the Review Queue, so mods can check the new topic for compliance. Currently I flag the first post in the new topic, using the API. This works, but it does look like a bad thing when viewing the user’s admin history. Is there another way that doesn’t make the user look bad?

1 Like

Is there a reason you can’t use approve new topics unless trust level? This is built into Discourse.

2 Likes

I agree that would work for many use cases. We require tags from multiple tag groups, which is not supported by Discourse. We want to allow the new topic, without approval, but ensure the tags are correct as time permits.

I guess what I’m suggesting is a way to place arbitrary items on the review queue. Currently there are three supported types: flagged post, queued post, and user. We’re hijacking flagged post because it’s the closest to what we want, but it would be nice to place a “review tags” item on the review queue, even if we can only do so from the API.

1 Like

There is no easy way to do what you want.

The best way to do it would be to create a plugin that adds a new reviewable type, and then some kind of endpoint to create them.

1 Like

Is there a way to disable this dialog? We almost exclusively reject spammers, and this just adds one click to our workflow:

image

3 Likes

I’ve posted about the same issue here: Account rejection email - #11 by simon.

3 Likes

When the rejection reason is a spam one, we definitely don’t need this dialog @sam @Roman_Rizzi

2 Likes

Is there a way to add a reviewable of type “User” to the review queue via the API? Or is that only accessible to the code that creates a new user?

My use case is that I want mods to review any user updates to make sure they are compliant with policy. So I have a user_updated webhook, and want to put the updated user on the review queue.

I am able to reverse-engineer how to flag a post (/post_actions…) because I can manually flag a post and watch the network traffic, but I don’t know how to do the same for a User. I imagine it’s something like /user_actions…

1 Like

There is no way to do this via API at the moment. I think you’d have to add a plugin that intercepts an update to a user and creates a reviewable.

2 Likes

2 posts were split to a new topic: Responding to post approvals

Hi there, this is intended as constructive criticism of the review queue.

I know that some improvements have been made to the “Reject / Approve” buttons to make them less ambiguous (“Am I approving the post or am I approving the flag?”). But there is still a dual meaning to those status, which makes reviewing the list of already handled items quite confusing for me because the Status filter and Status in the top right doesn’t really mean anything. Here are some examples:

Approved post flagged for typing too fast → Post approved → Status: Approved

Approved flag on inappropriate post → Post rejected → Status: Approved

Rejected user for profile spam → User suspended → Status: Rejected

Rejected flag on a post → Post remains → Status: Rejected

So it seems like it needs to differentiate between the following statuses, and some items could have both:

  • User/post approved
  • User/post rejected
    ---
  • Moderation approved
  • Moderation rejected

Another suggestion for improvement in the case of user profile spammers, I would appreciate an option to delete the account and block the email but not the IP address, since they often use shared IP ranges that legitimate users could also be using.

1 Like