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)
Does a “user delete” webhook get triggered?
3 إعجابات
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)
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 إعجابات
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 إعجابات
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 إعجابات
@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)
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 إعجابات
I think this is a great suggestion @Roman - can you add to your list?
5 إعجابات
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)
Is there a reason you can’t use approve new topics unless trust level? This is built into Discourse.
إعجابَين (2)
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)
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)
Is there a way to disable this dialog? We almost exclusively reject spammers, and this just adds one click to our workflow:
3 إعجابات
I’ve posted about the same issue here: Account rejection email - #11 by simon.
3 إعجابات
إعجابَين (2)
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)
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)
تم تقسيم منشورين إلى موضوع جديد: الاستجابة لموافقات المنشورات
مرحباً، هذا نقد بنّاء لقسم مراجعة المحتوى.
أعلم أنه تم إجراء بعض التحسينات على أزرار “رفض / موافقة” لجعلها أقل غموضًا (“هل أوافق على المنشور أم أوافق على العلامة؟”). ولكن لا يزال هناك معنى مزدوج لهذه الحالات، مما يجعل مراجعة قائمة العناصر التي تم التعامل معها بالفعل مربكة للغاية بالنسبة لي لأن عامل تصفية الحالة والحالة في أعلى اليمين لا يعنيان شيئًا حقًا. إليك بعض الأمثلة:
تمت الموافقة على منشور تم وضع علامة عليه بسبب الكتابة بسرعة كبيرة – تمت الموافقة على المنشور – الحالة: تمت الموافقة
تمت الموافقة على علامة على منشور غير لائق – تم رفض المنشور – الحالة: تمت الموافقة
تم رفض مستخدم بسبب بريد عشوائي في الملف الشخصي – تم تعليق المستخدم – الحالة: مرفوض
تم رفض علامة على منشور – يبقى المنشور – الحالة: مرفوض
لذلك يبدو أنه يحتاج إلى التمييز بين الحالات التالية، ويمكن أن يكون لبعض العناصر كلتاهما:
- تمت الموافقة على المستخدم/المنشور
- تم رفض المستخدم/المنشور
--- - تمت الموافقة على الإشراف
- تم رفض الإشراف
اقتراح آخر للتحسين في حالة مرسلي البريد العشوائي في ملفات تعريف المستخدمين، سأقدر خيار حذف الحساب وحظر البريد الإلكتروني ولكن ليس عنوان IP، لأنهم غالبًا ما يستخدمون نطاقات IP مشتركة يمكن للمستخدمين الشرعيين استخدامها أيضًا.
إعجاب واحد (1)