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 « J'aime »
Does a “user delete” webhook get triggered?
3 « J'aime »
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 « J'aime »
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 « J'aime »
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 « J'aime »
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 « J'aime »
@Roman - 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 « J'aime »
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 « J'aime »
I think this is a great suggestion @Roman - can you add to your list?
5 « J'aime »
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 « J'aime »
Is there a reason you can’t use approve new topics unless trust level? This is built into Discourse.
2 « J'aime »
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 « J'aime »
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 « J'aime »
Is there a way to disable this dialog? We almost exclusively reject spammers, and this just adds one click to our workflow:
3 « J'aime »
I’ve posted about the same issue here: Account rejection email - #11 by simon.
3 « J'aime »
2 « J'aime »
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 « J'aime »
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 « J'aime »
2 messages ont été déplacées vers un nouveau sujet : Répondre aux approbations de messages
Salut, ceci est une critique constructive de la file d’attente de révision.
Je sais que des améliorations ont été apportées aux boutons « Rejeter / Approuver » pour les rendre moins ambigus (« Est-ce que j’approuve le message ou est-ce que j’approuve le signalement ? »). Mais il y a toujours une double signification à ces statuts, ce qui rend la révision de la liste des éléments déjà traités assez confuse pour moi car le filtre Statut et le Statut en haut à droite n’ont pas vraiment de sens. Voici quelques exemples :
Message approuvé signalé pour avoir tapé trop vite – > Message approuvé → Statut : Approuvé
Signalement approuvé sur un message inapproprié → Message rejeté → Statut : Approuvé
Utilisateur rejeté pour spam de profil → Utilisateur suspendu → Statut : Rejeté
Signalement rejeté sur un message → Message conservé → Statut : Rejeté
Il semble donc qu’il faille différencier les statuts suivants, et certains éléments pourraient avoir les deux :
- Utilisateur/message approuvé
- Utilisateur/message rejeté
--- - Modération approuvée
- Modération rejetée
Une autre suggestion d’amélioration dans le cas des spammeurs de profils utilisateurs, j’apprécierais une option pour supprimer le compte et bloquer l’adresse e-mail mais pas l’adresse IP, car ils utilisent souvent des plages d’adresses IP partagées que des utilisateurs légitimes pourraient également utiliser.
1 « J'aime »