Ciao, ho riscontrato un problema iniziato diverse versioni di Discourse fa: ricevo notifiche su un nuovo utente in attesa di approvazione, ma scoprendo poi che la coda di revisione è vuota.
Questo accade solo quando un singolo utente richiede l’approvazione. Se ci sono più persone in attesa, riesco a vederle tutte tranne una nella coda, ma una manca sempre.
In altre parole, molte persone non sono state in grado di registrarsi.
In un thread separato è stato suggerito che il plugin multi-select potrebbe essere in qualche modo coinvolto, causando l’aggiunta di un utente alla lunghezza della coda da parte di Discourse.
Nel complesso, questo sembra improbabile, dato che qualcosa deve accadere per attivare la notifica in alcuni giorni e non in altri. Inoltre, il problema non è iniziato quando il plugin è stato installato, ma alcuni mesi dopo; posso correlarlo solo a un aggiornamento di Discourse (poiché non credo siano stati apportati altri plugin o modifiche da allora).
Qualcun altro ha riscontrato questo problema? E qual potrebbe essere la soluzione?
Per un caso di fortuna, @jjaffeux, è possibile che la modifica “FIX: makes value parsing more resilient” che hai apportato a questo plugin possa essere coinvolta in questo problema?
Ciao - Anche io non sono chiaro, potrebbe essere entrambe le cose?
Il problema non è iniziato quando il plugin è stato installato per la prima volta, ma è cominciato alcune aggiornamenti principali fa. Se il plugin è coinvolto in qualche modo, forse c’è qualche interazione non intenzionale?
Non posso davvero testare la disinstallazione del plugin per vedere se il problema persiste, poiché è fondamentale: la verifica delle iscrizioni degli utenti dipende dalle risposte che possono fornire solo con questo plugin attivo (gli utenti devono fare delle selezioni da un menu a tendina).
Credo che il mio primo consiglio qui sia di attendere lo “stato errato”… quindi abilitare la modalità sicura per il tuo browser e verificare se la coda appare corretta.
Se in modalità sicura tutto sembra a posto, probabilmente vorrai pubblicare su Marketplace per chiedere la conversione del plugin in un componente del tema e l’aggiornamento agli ultimi pattern di Discourse.
Purtroppo, gli stessi risultati si verificano in modalità sicura: in risposta a una notifica di utenti in attesa, manca ancora uno dalla coda da revisionare, anche quando visito in modalità sicura di Discourse con tutti e tre gli elementi di personalizzazione del sito disabilitati.
È possibile che sia necessario un esperto della coda di revisione per dare un’occhiata a questo argomento. Segnalerò la questione e qualcuno ti risponderà nei prossimi giorni.
Sarebbe incredibilmente utile avere i passaggi esatti per riprodurre il problema.
Grazie, Sam.
È molto difficile identificare i passaggi esatti: non sono sicuro di aver fatto qualcosa di insolito e non riesco a collegare l’insorgenza del problema a un evento specifico.
Secondo me, i principali sospettati sono un aggiornamento di Discourse o un aggiornamento del plugin multi-select di @j.jaffeux del 14 marzo, per “rendere l’analisi dei valori più robusta”.
Il problema è che le nuove iscrizioni sono così intermittenti che possono passare settimane senza che ne avvenga una, quindi causa ed effetto possono essere molto distanti nel tempo.
Ok, è stato interessante: ho provato a utilizzare il mio account Gmail come descritto sopra, ma anche aprendo la pagina di Gmail in un’altra finestra del browser e aspettando che arrivasse l’email di verifica generata da Discourse, ho ricevuto una notifica tramite il mio indirizzo email amministratore abituale riguardo a una nuova registrazione da esaminare (e la coda era vuota come prima). Avevo sbagliato a digitare l’indirizzo, quindi non ho mai ricevuto l’email sul mio account Gmail e non ho mai completato la verifica.
Quindi, a meno che non si tratti di una coincidenza, forse le notifiche agli amministratori si attivano troppo presto? Anche se questo non spiegherebbe perché OGNI notifica riguardi esattamente una persona mancante nella coda: presumibilmente non ci sarà sempre un fallimento nella verifica dell’indirizzo email da parte di un singolo candidato e non degli altri.
** Modifica
Successivamente, ho corretto l’indirizzo Gmail in quella finestra di iscrizione in incognito e ho rispedito l’email di verifica, che poi è arrivata nella finestra del browser di Gmail. Ho completato la verifica utilizzando l’URL di verifica in un’altra finestra in incognito con successo. Non è stata inviata alcuna notifica successiva al mio indirizzo email amministratore, quindi posso solo supporre che la prima notifica fosse effettivamente associata a questo tentativo di iscrizione.
Usando un’altra finestra del browser, ho visitato di nuovo il sito in modalità provvisoria, ho effettuato l’accesso come amministratore e ho visto la stessa coda con ancora una persona da esaminare: ma questa volta il mio nuovo account di test era visibile e poteva essere approvato.
Per fare seguito: ho riprovato e ho creato un nuovo account finto tramite una finestra di navigazione in incognito (con l’indirizzo corretto al primo tentativo) - questo tentativo ha funzionato come previsto e, rispondendo alla notifica dell’amministratore ricevuta via email tramite una finestra del browser normale, ho visto che il nuovo utente era visibile nella coda.
Ho ripetuto la procedura con una nuova registrazione tramite una finestra normale, rispondendo alla notifica tramite una finestra normale (senza incognito o modalità protetta in nessun momento) - e ancora una volta tutto ha funzionato come dovrebbe. Quindi il problema (o forse due problemi: la notifica all’amministratore anche prima della verifica dell’indirizzo email da parte del richiedente, e la mancata visualizzazione della domanda incompleta o completata nella coda) era limitato al primo tentativo.
Di nuovo, non sono sicuro che questo aggiunga molta chiarezza, ma forse, dopo che il sistema ha fallito un primo tentativo di registrazione (generando una notifica fantasma), le registrazioni successive funzionano correttamente? Forse il sistema torna in modalità di errore dopo un periodo sufficiente senza ulteriori attività di registrazione?
Sospetto che una migrazione che ho aggiunto più o meno nello stesso momento del commit che hai menzionato abbia causato questo problema, facendo apparire alcuni utenti non approvati nella coda di revisione e generando notifiche strane.
Puoi eseguire questa query nell’esploratore dati per confermare che sia effettivamente così?
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
Tuttavia, la mia installazione di Discourse mostra attualmente anche che non ci sono utenti in attesa.
Ho appena creato un altro account finto e ho fatto verificare l’indirizzo, ma finora non è stata inviata alcuna notifica al mio indirizzo email di amministratore. Accedendo di nuovo al mio sito come amministratore, ho rieseguito la query e il conteggio era di nuovo zero, ma questa volta Discourse segnala correttamente (come dovrebbe) che c’è un utente in attesa di revisione
Normalmente le email di notifica per gli utenti da revisionare arrivano quasi immediatamente al mio indirizzo di amministratore, quindi sono abbastanza sicuro che questa non sia mai stata inviata. Ora ho quasi il problema opposto!
*EDIT - Ho appena ricevuto una notifica che DUE utenti erano in attesa di revisione (dopo un ritardo insolito). Tuttavia, la piccola icona rossa accanto al menu hamburger mostrava il numero ‘1’, e cliccando per esaminare la coda appariva solo la mia singola registrazione di utente finto creata sopra, che ho approvato. Discourse ha poi indicato che non ci sono più utenti da revisionare.
Dopo di ciò ho rieseguito la query e il conteggio era zero.
Mi scuso, ho realizzato che la clausola WHERE è errata. Dovrebbe essere r.type = 'ReviewableUser' invece di User.
Puoi eseguire questo invece?
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
Ciao Roman,
appena ho ricevuto un altro messaggio fantasma, poi leggendo il tuo ultimo messaggio ho eseguito la nuova query: stesso risultato - count=0
Potresti controllare se il tuo sito ha utenti non approvati senza un oggetto verificabile associato? Ho cercato di riprodurre questo bug finora senza successo.
Ecco una query per farlo:
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
Inoltre, prova:
SELECT COUNT(*) FROM users WHERE approved = false AND active = true
Non sono sicuro che sia rilevante, ma ci sono molti post importati da un gruppo Yahoo ormai defunto, che è il precursore dell’attuale forum: sono stati uniti per garantire continuità e ricercabilità. I creatori di quei vecchi post (risalenti all’inizio degli anni 2000) spesso non hanno account sul forum attuale.
È stato molto interessante: come può qualcuno avere un account non approvato ma essere attivo? A meno che non si tratti di me in qualità di amministratore? Come posso modificare la query per identificare quell’utente?
Significa semplicemente che è in attesa di approvazione.
SELECT * FROM users WHERE approved = false AND active = true
Il nome utente sarà un link al profilo dell’utente. Dopo averlo identificato, puoi condividere la data created_at? Vorrei sapere se abbiamo apportato qualche modifica intorno a quella data.
