The delete user action is found under different top level buttons depending on the type of flag. It would be nice if the Delete button always had a delete user sub action.
And btw, URLs are added to the screened list if you delete from a manually flagged review, just not from user posted too fast reviews.
I just had some odd things happen relating to flagging of a post in a personal message. Two people are in the message (myself and a new moderator I am in the process of onboarding). We were testing out flagging, and she flagged one of her own posts. Both of us received the notification that our message was flagged as spam and that we should edit and fix it, and neither of us could directly reverse the flagging action directly in the post. It also did not show up in the review queue.
While the post was hidden, I selected the post admin wrench but was unable to use it because it was somehow behind the post content. See screenshot.
Only when I edited the post did it get unhidden.
So… several issues:
I’ve been loving the improvements here - I’ve finally had a chance to collect my thoughts and accumulate a bit of feedback about this:
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).
