L’action « Supprimer l’utilisateur » se trouve sous différents boutons de premier niveau selon le type de drapeau. Il serait pratique que le bouton Supprimer propose toujours une sous-action « Supprimer l’utilisateur ».
Au passage, les URL sont ajoutées à la liste filtrée si vous supprimez depuis un signalement manuel, mais pas depuis les signalements « publié trop rapidement » par l’utilisateur.
Je viens de rencontrer des comportements étranges liés au signalement d’un message dans un message privé. Il y avait deux personnes dans le message (moi-même et un nouveau modérateur que je suis en train d’intégrer). Nous testions la fonction de signalement, et elle a signalé l’un de ses propres messages. Nous avons tous deux reçu la notification indiquant que notre message avait été signalé comme spam et que nous devions le modifier pour le corriger. Aucun de nous deux n’a pu annuler directement l’action de signalement depuis le message. De plus, le message n’est pas apparu dans la file d’examen.
Lorsque le message était masqué, j’ai essayé d’utiliser l’outil d’administration (la clé à molette) du message, mais je n’ai pas pu y accéder car il semblait être caché derrière le contenu du message. Voir la capture d’écran.
Ce n’est qu’après avoir modifié le message qu’il a été réaffiché.
Donc… plusieurs problèmes :
J’adore les améliorations apportées ici – j’ai enfin eu l’occasion de rassembler mes idées et de compiler un peu de retours à ce sujet :
Une autre fonctionnalité que nous devrions ajouter : faire en sorte que les éléments re-dénoncés n’apparaissent pas à nouveau dans la file d’examen, sauf si le contenu du message a été modifié ou changé d’une manière ou d’une autre. Cela devrait ignorer automatiquement les nouveaux éléments de signalement et empêcher la notification ou le masquage du message.
L’idée ici est qu’un modérateur a déjà vu le signalement et l’a traité, et que tout nouvel élément (du même type) serait traité de la même manière.
Une mise en garde à ce sujet : nous devrions probablement ignorer les nouveaux signalements plutôt que de résoudre automatiquement l’élément examiné de la même manière que le signalement a été réellement traité (par exemple, « d’accord »), car cela pourrait avoir l’effet secondaire non désiré de permettre aux trolls de signalement d’augmenter leurs scores de signalement en signalant des éléments que les modérateurs ont résolus avec « d’accord + garder ».
Bonne remarque. Pour compléter, j’approuve régulièrement des publications qui sont ensuite signalées comme spam par Akismet. Cela ne devrait probablement pas se produire non plus.
Oh oui, les plugins devraient probablement toujours pouvoir outrepasser la suggestion ci-dessus si nécessaire, mais je suis d’accord pour dire qu’Akismet ne devrait pas le faire dans ce cas. Cela pourrait davantage relever d’un problème lié au plugin Akismet, mais c’est un excellent point.
Il s’agit d’un problème lié au plugin, je vais pousser une correction.
J’ai déjà commencé à examiner cela. Je suis d’accord pour dire que nous devons ignorer les nouveaux signalements plutôt que de les résoudre automatiquement. Je pensais afficher un message d’erreur lorsqu’un utilisateur tente de re-signaler une publication déjà examinée.
Je pensais également que les utilisateurs devraient attendre environ 24 heures avant de pouvoir re-signaler une publication pour la même raison.
Puisque tous les derniers éléments en attente se trouvent dans le menu Tout afficher, l’onglet Révision devrait nous rediriger vers ce menu plutôt que vers le menu Regroupé par sujet.
Avez-vous défini des « sujets par défaut révisables » ? Cela entraîne le basculement vers les sujets par défaut au lieu de tous les éléments, ce qui devrait être la valeur par défaut.
Nous venons de fusionner cette fonctionnalité :
Selon Discourse 2.4.0.beta11 Release Notes :
Utilisateurs suspects envoyés dans la file d’examen
Les utilisateurs suspects, c’est-à-dire ceux qui ont consulté moins d’un message et d’un sujet mais ont personnalisé leur biographie, sont désormais envoyés dans la file d’examen. De tels utilisateurs ont une forte probabilité d’être des spammeurs, car la plupart des utilisateurs parcourent le site avant de prendre le temps de remplir leur biographie.
Cela ne se produit pas chez nous ; les nouveaux utilisateurs suspects apparaissent dans /admin/users/list/suspect comme d’habitude, mais pas dans la file d’examen. Cela dépend-il de certains paramètres ?
Oui, cette fonctionnalité dépend du paramètre « Approuver les utilisateurs suspects » (désactivé par défaut).
Super, ça fonctionne maintenant (peut-être que ce genre d’informations devrait être ajouté aux notes de version).
J’ai cependant une petite demande qui nous aiderait à accélérer le processus de révision : pourriez-vous ajouter un lien au champ du site web ? Pour l’instant, nous devons le copier/coller, ce qui nous ralentit considérablement.
Cela ressemble à un champ utilisateur que vous avez ajouté. Malheureusement, nous n’avons aucun moyen de savoir s’il s’agit d’URL ou non.
Le champ « Site web » ? Ce n’est pas un champ personnalisé (comme ici sur Meta). Les deux autres le sont, mais je n’ai pas besoin qu’ils soient liés directement.
C’est logique que le champ du site web standard soit actif. Ce serait cool s’il incluait un suivi du nombre de clics.
Je pense que vous devriez pouvoir rendre vos champs personnalisés cliquables via un composant de thème.
Double-clic, contrôle - c, contrôle - t, contrôle - v, entrée
Ma faute ! J’ai vérifié ici sur Meta et l’utilisateur que j’ai regardé n’avait pas de site web. De plus, je me suis confondu avec les autres champs d’utilisateur situés juste en dessous. Cela permettra de lier le site web pour faciliter la révision :
Après y avoir réfléchi davantage, une période de réflexion de 24 heures semble convenable pour les petits sites, mais je crains que les utilisateurs puissent toujours submerger les modérateurs sur un grand site.
Que pensez-vous de rendre la variable de fenêtre « non signalable » modifiable (ou du moins accessible via un plugin) ? Toute mesure permettant de réduire la charge potentielle pour les modérateurs serait un succès.
Un autre problème sans rapport : les utilisateurs très fiables pourraient être perçus comme ayant des pouvoirs de « modérateur » avec la capacité de masquer un message avec un seul signalement. L’ancien nombre minimum requis pour masquer un message pourrait toujours être une option souhaitable, afin qu’aucun membre de la communauté ne puisse agir seul comme censeur.
Ouais, après pas mal d’allers-retours, je ne suis plus vraiment opposé à réintroduire le nombre minimum. J’aimerais juste m’assurer que le client de @featheredtoast a déjà essayé les autres ajustements et est certain que cela serait utile.
@Roman, pourrions-nous rendre cette fenêtre de 24h configurable ?
Fait ici :
Peut être activé ou désactivé avec le paramètre high_trust_flaggers_auto_hide_posts.
Peut être configuré à l’aide du paramètre cooldown_hours_until_reflag (par défaut 24 heures).
