Une suggestion pour le système d’examen : lors de l’approbation d’un message qui débloque un utilisateur, pourriez-vous ajouter une note utilisateur pour cet événement ? Quelque chose comme '@nomdutilisateur a débloqué ce compte' serait très utile. Pour l’instant, nous ne voyons que la moitié de l’histoire dans les notes.
Il vaut mieux les supprimer purement et simplement, c’est ce que je fais. Elles sont généralement erronées de toute façon, et je n’aime pas les notes bruyantes qui n’apportent aucune information.
Depuis la file d’examen, pour le type « Publication en file d’attente », si j’essaie de supprimer un utilisateur qui a un grand nombre de publications, je rencontre une erreur de délai d’attente 502.
Je ne suis pas sûr de la limite supérieure, mais lors des tests effectués aujourd’hui, le plus faible nombre de publications que j’ai essayé et qui ne fonctionnait pas concernait un compte avec 288 publications.
Par exemple, dans le cas où une publication a été signalée (type : Publication en file d’attente) car elle contient un mot figurant sur la liste « Mots surveillés → Nécessite une approbation ».
Actuellement, les options disponibles sont :
Approuver la publication | Rejeter la publication | Supprimer l’utilisateur | Modifier
Je pense que l’ajout des options de mise en silence et de suspension pour ces types de publications en file d’attente serait très utile. Par exemple : rejeter la publication et mettre en silence ou suspendre. Cela donnerait aux administrateurs le choix entre mettre en silence/suspendre un utilisateur ou l’effacer de l’historique directement depuis la file d’examen.
De plus, si la suppression d’utilisateurs ayant plus de x publications depuis la file d’examen n’est pas viable en raison d’erreurs 502, avoir la suspension et la mise en silence comme options alternatives serait vraiment excellent.
Quelques informations supplémentaires :
Lorsque j’ouvre « Regroupé par sujet » depuis la file d’examen, je reçois cette erreur :
Erreur serveur
lors du chargement de /review/topics
Code d’erreur : 500 Internal Server Error
Notez qu’il y a environ 30 000 éléments dans la file d’examen, dont beaucoup d’éléments plus anciens ont été ajoutés par Akismet avant que je ne le désinstalle.
–
Problème de défilement/pagination (j’aurais probablement dû poster cela ici à la place) : Review Queue Pagination/Infinite Scrolling after Taking an Action
–
Concernant les éléments de type « (type: Queued Post) » et l’erreur de délai d’attente 502 lors de l’utilisation de l’option supprimer l’utilisateur. Je peux confirmer l’erreur avec un compte comportant 166 publications.
–
Idées :
-
Il serait utile d’avoir un lien direct vers la page d’administration de l’utilisateur depuis la file d’examen quelque part.
-
Je pense qu’il n’est actuellement pas possible de se désabonner de l’e-mail de rappel quotidien « x éléments doivent être examinés ». Il serait utile de pouvoir se désabonner.
Pouvez-vous consulter vos /logs et nous indiquer quelle est l’erreur ?
D’accord, je pense que c’est ça :
ActiveRecord::SubclassNotFound (Le mécanisme d’héritage par table unique n’a pas pu localiser la sous-classe : ‘ReviewableAkismetPost’. Cette erreur est levée car la colonne ‘type’ est réservée au stockage de la classe en cas d’héritage. Veuillez renommer cette colonne si vous n’aviez pas l’intention de l’utiliser pour stocker la classe d’héritage, ou redéfinir Reviewable.inheritance_column pour utiliser une autre colonne pour cette information.)
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activerecord-6.0.3/lib/active_record/inheritance.rb:234:in `rescue in find_sti_class’
Pouvez-vous confirmer si votre plugin Akismet est à la dernière version et, dans le cas contraire, le mettre à jour ?
Peut-être que les anciens éléments ajoutés par d’autres types d’avis ne peuvent pas être lus si la définition de l’élément révisable disparaît (comme lors de la désinstallation d’un plugin). Il semble que les erreurs aient commencé après la désinstallation :
Je peux confirmer qu’Akismet est actuellement désinstallé ; je l’ai retiré il y a déjà longtemps.
Oh, c’est intéressant, comme le soupçonne @featheredtoast. @Roman, comment penses-tu que nous devrions gérer cela si les enregistrements existent toujours mais que le plugin a été supprimé ?
Je pense qu’il est possible de déterminer quels types de révisables doivent être filtrés en procédant comme suit :
class Reviewable < ActiveRecord::Base
def self.exclude_types
db_types = Reviewable.distinct.pluck(:type)
@exclude_types ||= db_types - Reviewable.types
end
...
end
Ensuite, nous pouvons utiliser ces types pour appliquer une portée par défaut. Nous devrons probablement ajouter un index sur le champ type dans la table.
@Roman, peux-tu t’en occuper quand tu as un moment ?
Je reçois beaucoup d’images invisibles dans la file d’examen des avis. Certaines fonctionnent parfaitement, c’est environ 50/50. Certaines affichent quelque chose comme ceci lors de l’inspection, mais rien ne s’affiche :
src="/images/transparent.png" alt="" data-orig-src="upload://fwf1zrfwefWEqGer2W3xz1ed.jpeg"
Cela se produit aussi bien pour les instances utilisant un CDN + S3 que pour celles utilisant uniquement le stockage local.
Oui, le problème n’affecte que les publications en file d’attente.
J’ai une PR avec une correction en attente de revue, donc les images devraient réapparaître bientôt.
Je vous tiendrai informé une fois qu’elle sera fusionnée.
La correction est désormais disponible sur les branches tests-passed et stable.
Cependant, il subsiste un autre problème : les images de publications en file d’attente rejetées n’apparaissent toujours pas dans la file d’examen. Le système les supprime automatiquement, car il n’est pas nécessaire de les conserver. Nous prévoyons de les remplacer par un texte expliquant cette situation.
Merci beaucoup d’avoir réglé ça @Roman !
Autre chose qui pourrait être un bug sur tests-passés : Scénario : Accepter un post dans la file d’attente de révision, puis revenir en arrière et le rejeter. Le post restera listé et visible sur le site.
Edit, les deux derniers paragraphes de ce commentaire expliquent également un autre problème possible avec certaines options liées à la file d’attente de révision et les limites de taux au niveau du site : Discourse No Bump - #27
Autre chose que j’ai remarquée concernant « l’âge de file d’attente géré automatiquement ». J’ai de nombreux éléments anciens dans certaines files d’attente de revue qui sont nettement plus âgés que le paramètre d’âge de file d’attente géré automatiquement (en utilisant la valeur par défaut), mais qui ne semblent pas être traités automatiquement. Il ne semble pas que l’un des éléments soit traité automatiquement. Je ne sais pas si j’ai manqué quelque chose.
De plus, lorsque je trie la file d’attente de revue par « Créé le (inverse) », j’obtiens une erreur 500. Tous les autres filtres « ordonner par » fonctionnent correctement.
Pouvez-vous vérifier vos journaux et nous indiquer quelle est l’erreur lorsque vous modifiez l’ordre de tri ?
Merci @eviltrout, oui bien sûr. Voici l’erreur que je vois :
ActiveRecord::SubclassNotFound (Le mécanisme d’héritage à table unique n’a pas pu localiser la sous-classe : ‘ReviewableAkismetPost’. Cette erreur est levée car la colonne ‘type’ est réservée pour stocker la classe en cas d’héritage. Veuillez renommer cette colonne si vous ne prévoyiez pas de l’utiliser pour stocker la classe d’héritage, ou redéfinir Reviewable.inheritance_column pour utiliser une autre colonne pour cette information.)
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activerecord-6.0.3.1/lib/active_record/inheritance.rb:234:in `rescue in find_sti_class’
Notez que le plugin Akismet a été supprimé il y a déjà quelque temps sur ce forum en particulier.
Ah, donc cela est toujours lié à cela. @Roman, il semble qu’il puisse y avoir encore un bug ici lié à la présence de ces anciens types de révisables dans la base de données ?
