Hai ragione. L’errore di ordinamento nella coda di revisione si verifica perché nel database sono presenti elementi da revisionare di Akismet dopo che il plugin è stato rimosso. Vedo due possibili soluzioni:
Fornire un task rake per rimuovere queste righe dal database prima che l’utente decida di rimuovere definitivamente il plugin.
Applicare un default scope alla classe Reviewable che escluda queste righe se il plugin è disabilitato.
Accade quando il post è in attesa di revisione? O dopo averlo respinto? Come ho detto prima, gli upload dei post in coda respinti vengono rimossi automaticamente dal sistema.
Credo che la disinstallazione di plugin sia un evento raro, mentre la gestione predefinita degli ambiti è più propensa a introdurre bug.
Penso che sarebbe ragionevole aggiungere un task Rake e inserirlo nel README, in una sezione dedicata alla “disinstallazione”, con istruzioni su come eseguirlo per rimuovere i vecchi record. Facciamo così!
Ho provato a disattivare ‘notifica sui post in coda dopo’ impostandolo a 0 e anche a 2000000000. Ricevo comunque molte frequenti notifiche del tipo ‘x elementi devono essere revisionati’.
Il sistema li sta inviando perché ci sono elementi in sospeso nella coda. L’impostazione che hai modificato riguarda i promemoria per i post in coda; imposta notify_about_flags_after a 0 invece.
Grazie @Roman - posso confermare che modificare notify_about_flags_after a 0 ha fermato le notifiche
Apprezzo davvero l’aggiunta del rake task per questo! Reinstallerò Akismet ed eseguirò il rake task più tardi oggi, quando il traffico è al minimo, per poi aggiornare questo post con i risultati.
Sembra che gli utenti i cui post vanno direttamente nella coda di revisione possano aggirare diversi limiti di velocità per la creazione di argomenti e post/risposte.
Opzioni di limite di velocità che sembrano aggirabili:
limite di velocità creazione argomento, limite di velocità nuovo utente creazione argomento, massimo argomenti al giorno, limite di velocità creazione post, limite di velocità nuovo utente creazione post, minuti tra post unici, massimo risposte consecutive.
Opzioni per inviare argomenti e post direttamente nella coda di revisione:
“approva numero di post” (nuovi utenti che devono far approvare i loro primi argomenti/post) nonché le opzioni individuali per categoria di “Richiedi l’approvazione del moderatore per tutti i nuovi argomenti” e molto probabilmente (ho testato solo l’opzione per i nuovi argomenti) “Richiedi l’approvazione del moderatore per tutte le nuove risposte”.
Ah, capito. Grazie per la spiegazione. Condividerò solo le mie esperienze a scopo di riferimento.
Senza l’applicazione dei limiti, viene consentito agli utenti nuovi (con approvazione basata sul numero di post) di inondare liberamente la coda di revisione con limiti nulli o minimi, mentre gli account più anziani e fidati sono soggetti ai limiti di frequenza. Tranne quando sono attivate le opzioni di categoria per l’approvazione di tutti gli argomenti o le risposte, caso in cui anche gli utenti fidati più anziani non hanno limiti o ne hanno di minimi.
Sarebbe un lavoro considerevole, ma abbastanza fattibile approvare tutti i nuovi argomenti, nonché gli argomenti/post iniziali creati dagli utenti nuovi (se soggetti a limiti di frequenza), ma nel mio caso è quasi impraticabile quando gli utenti possono inondare la coda.
Comunque, grazie mille per la chiarificazione che questo è previsto dal design. È molto utile. Penso che rivedrò la mia strategia e disattiverò le opzioni che inviano argomenti o post direttamente alla coda di revisione, riservandola principalmente ai contenuti segnalati. Moderare successivamente i contributi in tempo reale soggetti a limiti di frequenza dovrebbe funzionare bene ed essere anche più dinamico per gli utenti.
Ho recentemente impostato la configurazione del sito su “solo su invito” e ora c’è un elemento nella coda di revisione generato dal sistema per un account utente, contrassegnato come “Necessita approvazione”.
La cosa strana è che si tratta di un account esistente (di 4 anni) con diversi post e livello TL2, ma che non era attivo da tempo (l’ultimo post risale a 2 anni fa); tuttavia, ha effettuato l’accesso oggi, dopo di che è stato sollevato il flag di revisione.
Non ho ancora utilizzato la funzione “Approva utente” e l’elemento è ancora nella coda di revisione, ma sembra che l’account sia abilitato e in grado di utilizzare il forum (come dovrebbe).
Sembra che la coda di revisione stia identificando gli account riattivati di recente come nuovi account e li stia contrassegnando per la revisione quando è impostato “solo su invito”?
Modifica: questo è successo anche ora per un account molto recente, creato solo pochi giorni prima dell’attivazione di questa impostazione.
Credo di aver già visto questo prima, quando si passa alla modalità solo su invito. In alcune situazioni, Discourse pensa che sia necessario approvare l’utente perché ha ottenuto l’accesso al sito registrandosi normalmente. Quando si modifica quell’interruttore, il suo record non ha l’indicatore “Approvato” impostato.
Ho indagato ulteriormente e l’unica cosa che questi account (in totale quattro) hanno in comune è che tutti hanno effettuato l’accesso utilizzando uno dei percorsi di accesso tramite email (tramite forgot_password o direttamente tramite email_login) dopo che è stata impostata la modalità invite_only.
È stato mai preso in considerazione l’aggiunta dell’opzione Sospendi ai topic/post in revisione segnalati da Akismet? È stato suggerito sulla nostra istanza, semplicemente perché usiamo l’SSO, quindi eliminare gli utenti raramente serve a qualcosa: l’utente può semplicemente riaccedere al proprio account sul provider principale e verrà immediatamente connesso ai forum per continuare la sua navigazione. Sospendere l’account rende le cose più difficili, poiché dovranno creare un nuovo account sul provider con un nuovo indirizzo email.
So che è una richiesta un po’ strana, ma è qualcosa che i miei moderatori chiedono abbastanza frequentemente. Oggi devono manualmente aggirare il sistema per sospendere l’utente, il che crea un lavoro extra per loro, ma ne vale la pena perché l’utente, alla fine, non è disposto a scartare un altro indirizzo email.