Bonjour, je rencontre un problème qui a commencé il y a plusieurs mises à jour de Discourse : je reçois des notifications indiquant qu’un nouvel utilisateur est en attente d’approbation, mais la file d’examen est vide.
Cela ne se produit que lorsqu’un seul utilisateur demande une approbation. Si plusieurs personnes sont en attente, je peux voir toutes les demandes sauf une dans la file — mais il manque toujours une personne.
Autrement dit, beaucoup de personnes n’ont pas pu s’inscrire.
Dans un fil de discussion distinct, il a été suggéré que le plugin de sélection multiple pourrait être impliqué et amener Discourse à ajouter un élément à la longueur de la file d’attente.
Dans l’ensemble, cela semble peu probable, car quelque chose doit se produire pour déclencher une notification certains jours et pas d’autres. De plus, le problème n’a pas commencé lors de l’installation du plugin ; il a émergé plusieurs mois plus tard, et je ne peux le corréler qu’à une mise à jour de Discourse (car je ne pense pas qu’aucun autre plugin ou changement n’ait été effectué depuis).
Quelqu’un d’autre a-t-il rencontré ce problème ? Et quelle pourrait être la solution ?
Au cas où, @jjaffeux, est-il possible que la modification « FIX: makes value parsing more resilient » que vous avez apportée à ce plugin soit impliquée dans ce problème ?
Bonjour, je ne suis pas plus clair non plus. Est-ce que cela pourrait être les deux ?
Le problème ne s’est pas manifesté lors de l’installation initiale du plugin, mais il a commencé il y a quelques mises à jour principales. Si le plugin est en cause, peut-être y a-t-il une interaction non intentionnelle ?
Je ne peux pas vraiment tester la désinstallation du plugin pour voir si le problème persiste, car il est critique pour notre activité : la vérification des inscriptions des utilisateurs dépend des réponses qu’ils ne peuvent fournir que lorsque ce plugin est actif (les utilisateurs doivent faire des choix dans une liste déroulante).
Je pense que ma première recommandation ici serait d’attendre l’état « problématique »… puis d’activer le mode sans échec de votre navigateur et de vérifier si la file d’attente semble correcte.
Si cela semble correct en mode sans échec, vous voudrez probablement poster sur Marketplace pour demander la conversion du plugin en composant de thème et sa mise à jour vers les derniers modèles de Discourse.
Malheureusement, les résultats sont les mêmes en mode sans échec : suite à une notification d’utilisateurs en attente, il en manque toujours un dans la file d’attente à examiner, même lorsque je me connecte en mode sans échec de Discourse avec les trois éléments de personnalisation du site désactivés.
Il est possible que nous ayons besoin d’un expert en file d’attente de révision pour examiner ce sujet. Je vais signaler cela et quelqu’un reviendra vers vous dans les prochains jours.
Les étapes exactes pour reproduire le problème seraient incroyablement utiles.
Merci, Sam.
Il est très difficile d’identifier les étapes exactes — je ne suis pas sûr d’avoir fait quelque chose d’inhabituel, et je ne peux pas rattacher le début du problème à un événement spécifique.
À mon avis, les principaux suspects sont soit une mise à jour de Discourse, soit une mise à jour du plugin multi-sélection par @j.jaffeux le 14 mars pour « rendre l’analyse des valeurs plus résistante ».
Le problème est que les nouvelles inscriptions sont si intermittentes que des semaines peuvent s’écouler sans qu’aucune ne se produise, de sorte que la cause et l’effet peuvent être très éloignés dans le temps.
OK, c’était intéressant — j’ai essayé d’utiliser mon compte Gmail comme indiqué ci-dessus, mais même en ouvrant la page web de Gmail dans une autre fenêtre de navigateur et en attendant l’email de vérification généré par Discourse, j’ai été notifié via mon adresse email d’administrateur habituelle d’une nouvelle inscription à examiner (et la file d’attente était toujours vide comme avant). J’avais mal saisi l’adresse, donc je n’ai jamais reçu l’email sur mon compte Gmail, et je n’ai donc jamais pu vérifier.
Donc, sauf coïncidence, peut-être que les notifications aux administrateurs sont prématurées ? Bien que cela n’explique pas pourquoi CHAQUE notification concerne exactement une personne manquante dans la file d’attente — il est peu probable qu’il y ait toujours un échec de vérification d’adresse email pour un seul candidat et pas pour les autres.
** Modification
Par la suite, j’ai corrigé mon adresse Gmail dans cette fenêtre de connexion en navigation privée et j’ai renvoyé l’email de vérification — qui est alors apparu dans ma fenêtre de navigateur Gmail. J’ai validé cela en utilisant l’URL de vérification dans une autre fenêtre de navigation privée, avec succès. Aucune notification ultérieure n’a été envoyée à mon adresse email d’administrateur, je ne peux donc que supposer que la première notification était bien liée à cette tentative d’inscription.
En utilisant une autre fenêtre de navigateur, j’ai de nouveau visité le site en mode sans échec, connecté en tant qu’administrateur, et j’ai vu la même file d’attente avec toujours une personne à examiner — mais cette fois, mon nouveau compte de test était visible et pouvait être approuvé.
Pour faire suite : j’ai réessayé et créé un nouveau faux compte via une fenêtre de navigation privée (avec la bonne adresse dès la première fois) — cette tentative a fonctionné comme prévu, et en répondant à la notification par e-mail destinée à l’administrateur depuis une fenêtre de navigateur standard, j’ai constaté que le nouvel utilisateur était visible dans la file d’attente.
J’ai répété l’opération avec une nouvelle inscription via une fenêtre standard, et en répondant à la notification depuis cette même fenêtre standard (sans navigation privée ni mode sécurisé à aucun moment) — et là encore, tout a fonctionné normalement. Le problème (ou peut-être deux problèmes : la notification à l’administrateur même avant la vérification de l’adresse e-mail par le candidat, et l’absence d’apparition de la demande incomplète ou complète dans la file d’attente) était donc limité à la première tentative.
Encore une fois, je ne suis pas sûr que cela apporte beaucoup de clarté, mais peut-être qu’une fois qu’une première inscription a été échouée par le système (générant une notification fantôme), les inscriptions suivantes fonctionnent correctement ? Peut-être que le système revient en mode échec après un certain temps sans nouvelle activité d’inscription ?
Je soupçonne qu’une migration que j’ai ajoutée à peu près au même moment que le commit que vous avez mentionné est à l’origine de ce problème, faisant apparaître certains utilisateurs non approuvés comme s’ils étaient dans la file d’examen et provoquant des notifications étranges.
Pouvez-vous exécuter cette requête dans l’explorateur de données pour confirmer que c’est bien le cas ?
SELECT COUNT(*)
FROM users
INNER JOIN reviewables r ON r.target_id = users.id
WHERE r.type = 'User' AND r.status = 1 AND users.approved = FALSE
Cependant, mon installation Discourse n’affiche actuellement aucun utilisateur en attente.
Je viens de créer un autre faux compte et d’en faire vérifier l’adresse, mais aucune notification n’a encore été envoyée à mon adresse e-mail d’administrateur. En me reconnectant à mon site en tant qu’administrateur, j’ai relancé la requête, et le compteur était de nouveau à zéro, mais cette fois Discourse signale correctement (comme il se doit) qu’il y a un utilisateur en attente de validation
Habituellement, les e-mails de notification pour les utilisateurs à réviser arrivent presque immédiatement à mon adresse d’administrateur, donc je suis assez certain que celui-ci n’a jamais été envoyé. Maintenant, c’est presque le problème inverse !
*EDIT - Je viens de recevoir une notification indiquant que DEUX utilisateurs étaient en attente de révision (après un délai inhabituel). Pourtant, la petite icône rouge à côté du menu hamburger affichait toujours le chiffre « 1 », et en cliquant pour consulter la file d’attente, je ne voyais que mon propre faux compte créé précédemment – que j’ai approuvé, et Discourse a indiqué qu’il n’y avait plus d’utilisateurs à réviser.
Après cela, j’ai relancé la requête – et le compteur était de nouveau à zéro.
Désolé, j’ai réalisé que la clause WHERE est incorrecte. Elle devrait être r.type = 'ReviewableUser' au lieu de User.
Peux-tu exécuter celle-ci à la place ?
SELECT COUNT(*)
FROM users
INNER JOIN reviewables r ON r.target_id = users.id
WHERE r.type = 'ReviewableUser' AND r.status = 1 AND users.approved = FALSE
Bonjour Roman,
Je viens de recevoir un autre message fantôme, puis en lisant votre dernier message, j’ai exécuté la nouvelle requête — même résultat : count=0
Pourrais-tu vérifier si ton site compte des utilisateurs non approuvés sans objet révisable associé ? J’essaie de reproduire ce bug sans succès jusqu’à présent.
Voici une requête pour le faire :
SELECT COUNT(*)
FROM users u
LEFT JOIN reviewables r ON r.target_id = u.id AND r.type = 'ReviewableUser'
WHERE approved = false AND r.id IS NULL
Essaie aussi :
SELECT COUNT(*) FROM users WHERE approved = false AND active = true
Je ne sais pas si c’est pertinent, mais il y a beaucoup de posts importés d’un groupe Yahoo maintenant disparu, qui était l’ancêtre du forum actuel. Ils ont été fusionnés pour assurer la continuité et la recherche. Les auteurs de ces anciens messages (datant du début des années 2000) n’ont souvent pas de compte sur le forum actuel.
Voici les résultats de la deuxième requête ci-dessous :
C’était très intéressant : comment quelqu’un peut-il avoir un compte non approuvé tout en étant actif ? Sauf si c’est moi en tant qu’administrateur ? Comment puis-je modifier la requête pour identifier cet utilisateur ?
Cela signifie simplement qu’il est en attente d’approbation.
SELECT * FROM users WHERE approved = false AND active = true
Le nom d’utilisateur sera un lien vers le profil de l’utilisateur. Une fois que vous l’aurez identifié, pouvez-vous partager la date created_at ? J’aimerais savoir si nous avons modifié quelque chose autour de cette date.
