J’aimerais utiliser un webhook pour supprimer les spammeurs de notre base de données centrale lorsque je les supprime dans la file d’examen, mais aucun événement n’est déclenché lorsque je configure mon webhook de cette manière. Est-ce censé le faire, ou ai-je mal compris la partie « et lorsque son statut est mis à jour » ?
Un webhook « suppression d’utilisateur » est-il déclenché ?
C’est exact. Malheureusement, cela ne transmet pas une suppression, et je souhaiterais agir spécifiquement uniquement lorsqu’un utilisateur a été supprimé et bloqué par IP.
Je souhaiterais demander la possibilité de masquer automatiquement les images par défaut, en particulier pour les publications signalées par les utilisateurs de niveau TL0. Bien qu’il soit nécessaire de voir les images inappropriées et d’agir conformément aux normes de chaque communauté, il serait utile de masquer ces images pour les personnes travaillant dans des bureaux ou à domicile avec des enfants à proximité (ce qui est souvent mon cas).
L’API pour « contourner » l’exigence de notation par la file d’attente de modération reste insuffisante sur la durée, car la note est recalculée périodiquement. Si la file d’attente n’est pas traitée au moment de la création de l’élément révisable, l’élément « forcé » peut disparaître des listes à filtre élevé avant que les modérateurs ne puissent les examiner.
Peut-être devrions-nous ajouter un champ booléen force_review sur l’objet révisable, qui serait joint à la requête de score ici.
Les images des utilisateurs TL0 sont floutées par défaut. Cela peut être désactivé via le paramètre blur_tl0_flagged_posts_media.
Ceci est également fait. Lorsque le drapeau force_review est défini sur true, les éléments en attente de révision apparaîtront dans la file d’attente, même s’ils ne répondent pas au score seuil de visibilité minimale.
@Roman - Désolé, je n’ai pas encore pu revenir vers vous à ce sujet. Si cela reste potentiellement utile, j’ai récupéré les journaux et extrait certains enregistrements (anonymisés). Nous sommes actuellement sur la version 2.6.0beta3. Toutes les erreurs de type « integer out of range » semblent concerner le même type d’enregistrements.
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"
Ce serait également sympa d’avoir un moyen de voir une liste des éléments à réviser qui ont été traités, filtrés par le modérateur ayant géré les signalements. Le filtre « assigné à » lors de l’examen des signalements traités dans le passé semble sémantiquement très proche de la recherche d’un filtre « géré par », mais il est différent.
Le filtre « assigné à » avec des signalements/éléments à réviser résolus doit-il interroger qui a géré les signalements, ou peut-il s’agir d’un filtre distinct ?
Je pense que c’est une excellente suggestion @Roman — peux-tu l’ajouter à ta liste ?
J’utilise un webhook et l’API pour ajouter de nouveaux sujets à la file d’attente de modération, afin que les modérateurs puissent vérifier leur conformité. Actuellement, je signale le premier message d’un nouveau sujet via l’API. Cela fonctionne, mais cela donne une mauvaise impression lorsqu’on consulte l’historique d’administration de l’utilisateur. Existe-t-il une autre méthode qui ne nuise pas à la réputation de l’utilisateur ?
Y a-t-il une raison pour laquelle vous ne pouvez pas utiliser approuver les nouveaux sujets sauf niveau de confiance ? Cette fonctionnalité est intégrée à Discourse.
Je conviens que cela fonctionnerait pour de nombreux cas d’usage. Nous avons besoin d’étiquettes provenant de plusieurs groupes d’étiquettes, ce qui n’est pas pris en charge par Discourse. Nous souhaitons autoriser le nouveau sujet sans approbation, tout en veillant à ce que les étiquettes soient correctes selon le temps disponible.
Je pense que ce que je propose, c’est un moyen de placer des éléments arbitraires dans la file d’examen. Actuellement, trois types sont pris en charge : publication signalée, publication en file d’attente et utilisateur. Nous détournons la publication signalée car c’est ce qui se rapproche le plus de ce que nous voulons, mais il serait agréable de pouvoir ajouter un élément « examiner les étiquettes » dans la file d’examen, même si nous ne pouvons le faire que via l’API.
Il n’y a pas de moyen simple de faire ce que vous voulez.
La meilleure façon de procéder serait de créer un plugin qui ajoute un nouveau type révisable, ainsi qu’un certain type de point de terminaison pour les créer.
Y a-t-il un moyen de désactiver cette boîte de dialogue ? Nous rejetons presque exclusivement les spammeurs, et cela ajoute simplement un clic à notre flux de travail :
J’ai posté à propos du même problème ici : Account rejection email - #11 by simon.
Lorsque le motif de rejet est lié au spam, nous n’avons absolument pas besoin de cette boîte de dialogue @sam @Roman..
Existe-t-il un moyen d’ajouter un élément révisable de type « User » à la file d’examen via l’API ? Ou cela n’est-il accessible qu’au code qui crée un nouvel utilisateur ?
Mon cas d’usage est le suivant : je souhaite que les modérateurs examinent toutes les mises à jour des utilisateurs afin de s’assurer qu’elles sont conformes à la politique. J’ai donc un webhook user_updated et je souhaite ajouter l’utilisateur mis à jour à la file d’examen.
Je parviens à déduire comment signaler un message (/post_actions…) en signalant manuellement un message et en surveillant le trafic réseau, mais je ne sais pas comment procéder de la même manière pour un User. J’imagine que cela ressemble à /user_actions…
Il n’est pas possible de le faire via l’API pour le moment. Je pense que vous devrez ajouter un plugin qui intercepte une mise à jour d’un utilisateur et crée un élément révisable.
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.





