Je fais tourner mon site depuis plus d’un an et ce problème vient de se manifester récemment.
Nous avons de nombreux utilisateurs en attente d’approbation, le site servant principalement de centre d’assistance / de gestion de tickets.
Au cours de la dernière semaine environ, des tickets contenant des médias intégrés (captures d’écran) sont restés bloqués dans la file d’attente d’approbation.
Lorsque j’ai vérifié les « groupes de médias pour lesquels l’examen est ignoré », le TL0 y figure, mais je suppose que les utilisateurs en attente d’approbation pourraient avoir un drapeau légèrement différent.
Cela doit être corrigé, car des personnes manquent des tickets. Pourquoi cela vient-il de commencer ?
J’ai l’impression que ce rapport concerne le même problème
Je pense que les utilisateurs en phase de test étaient immunisés contre la plupart des limites. C’est pourquoi il existait le paramètre de site distinct Approuver sauf si en phase de test. Mais je n’ai pas utilisé cette fonctionnalité, donc je ne suis pas sûr.
Quelle raison est affichée dans la file d’examen ?
Je n’en ai pas actuellement en cours de révision, mais cela faisait référence au fait qu’il y avait des médias intégrés dans les publications à chaque fois.
J’ai vérifié ce paramètre « Approuver sauf si en brouillon » et il n’est pas coché.
Je continue à recevoir ces messages. Y a-t-il quelque chose que je puisse faire pour corriger le problème ?
Cela affecte vraiment notre flux de travail.
Désolé, je n’ai pas encore eu le temps d’y jeter un œil. Si c’est vraiment important pour toi, tu devrais envisager de demander de l’aide sur Marketplace.
J’ai testé cela à la fois directement avec NewPostManager et via le chemin réel d’envoi par e-mail. Un e-mail provenant d’un utilisateur en attente nouvellement créé, contenant des médias intégrés, a été publié immédiatement au lieu d’être envoyé à la file d’attente de modération.
Ainsi, pour une configuration de type service d’assistance où des expéditeurs arbitraires sont créés en tant qu’utilisateurs en attente, l’ajout de logged_in_users semble fournir le comportement attendu sans avoir besoin d’activer les utilisateurs ni de maintenir un groupe séparé.
Un détail légèrement surprenant est que les utilisateurs en attente correspondent au pseudo-groupe logged_in_users pour cette vérification, bien qu’ils ne soient pas des comptes activés/connectés au sens habituel du terme.
J’ai également ouvert une PR pour ajouter une couverture de régression pour ce comportement :
Elle vérifie qu’un utilisateur en attente (staged user) nouvellement créé avec des médias intégrés n’est pas mis en file d’attente lorsque logged_in_users est inclus dans skip_review_media_groups.
Cela devrait également clarifier si les mainteneurs considèrent qu’il est intentionnel, et donc fiable à l’avenir, qu’un utilisateur en attente corresponde à logged_in_users dans ce contexte.
