Un suggerimento per il sistema di revisione: quando si approva un post che riattiva un utente, potreste aggiungere una Nota Utente per l’evento? Qualcosa come '@username ha riattivato questo account' sarebbe molto utile. Al momento vediamo solo metà della storia nelle note.
3 Mi Piace
Meglio eliminarle del tutto, è quello che faccio io. Di solito sono comunque errate e non mi piacciono note rumorose che non aggiungono valore.
2 Mi Piace
Dalla coda di revisione, per il tipo ‘Post in coda’, se provo a eliminare un utente con un numero piuttosto elevato di post, ottengo un timeout 502.
Non sono sicuro qual sia il limite superiore, ma dai test effettuati oggi, il minimo che ho provato e che non ha funzionato è stato un account con 288 post.
Ad esempio, nel caso in cui un post sia stato segnalato (tipo: Post in coda) perché contiene una parola presente nell’elenco Parole monitorate → Richiedi approvazione.
Attualmente le opzioni disponibili sono:
Approva post | Rifiuta post | Elimina utente | Modifica
Credo che aggiungere le opzioni di silenziamento e sospensione a questi tipi di post in coda potrebbe essere molto utile. Ad esempio: Rifiuta post + silenzia o sospendi. Questo darebbe agli amministratori la possibilità di scegliere tra silenziare/sospendere un utente o cancellarlo direttamente dalla cronologia dalla coda di revisione.
Inoltre, se eliminare utenti con oltre X post dalla coda di revisione non è fattibile a causa degli errori 502, avere sospensione e silenziamento come opzioni alternative sarebbe davvero ottimo.
3 Mi Piace
Altre informazioni:
Quando apro “Raggruppati per argomento” dalla coda di revisione, ricevo questo errore:
Errore del server
mentre si cerca di caricare /review/topics
Codice di errore: 500 Internal Server Error
Si noti che ci sono circa 30.000 elementi nella coda di revisione; molti degli elementi più vecchi sono stati aggiunti da Akismet prima che lo disinstallassi.
–
Problema di scorrimento/paginazione (probabilmente avrei dovuto pubblicarlo qui invece): Review Queue Pagination/Infinite Scrolling after Taking an Action
–
Per quanto riguarda gli elementi (tipo: Post in coda) e il timeout 502 quando si usa l’opzione “Elimina utente”, posso confermare di ricevere l’errore con un account di 166 post.
–
Idee:
-
Sarebbe utile avere un collegamento diretto alla pagina di amministrazione dell’utente dalla coda di revisione, per risparmiare tempo.
-
Attualmente non sembra possibile disattivare l’email di promemoria giornaliera “x elementi devono essere revisionati”. Sarebbe utile poter scegliere di non riceverla.
2 Mi Piace
Puoi controllare i tuoi /log e farci sapere qual è l’errore?
3 Mi Piace
Ok, penso che sia questo:
ActiveRecord::SubclassNotFound (Il meccanismo di ereditarietà a tabella singola non è riuscito a individuare la sottoclasse: ‘ReviewableAkismetPost’. Questo errore viene generato perché la colonna ‘type’ è riservata per memorizzare la classe nel caso di ereditarietà. Rinomina questa colonna se non intendevi utilizzarla per memorizzare la classe di ereditarietà oppure sovrascrivi Reviewable.inheritance_column per utilizzare un’altra colonna per tale informazione.)
/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’
2 Mi Piace
Puoi confermare se il tuo plugin Akismet è l’ultima versione e, in caso contrario, aggiornarlo?
4 Mi Piace
Forse gli elementi vecchi aggiunti da altri tipi di revisione non possono essere letti se la definizione di oggetto revocabile scompare (ad esempio tramite la disinstallazione di un plugin). Sembra che gli errori siano iniziati dopo la disinstallazione:
4 Mi Piace
Posso confermare che Akismet è attualmente disinstallato; l’ho rimosso molto tempo fa.
1 Mi Piace
Oh, è interessante, come sospetta @featheredtoast. @Roman, secondo te come dovremmo gestire la situazione se i record sono presenti ma il plugin viene rimosso?
4 Mi Piace
Penso sia possibile determinare quali tipi di elementi revocabili devono essere filtrati facendo qualcosa del genere:
class Reviewable < ActiveRecord::Base
def self.exclude_types
db_types = Reviewable.distinct.pluck(:type)
@exclude_types ||= db_types - Reviewable.types
end
...
end
Possiamo quindi utilizzare quei tipi per applicare uno scope predefinito. Probabilmente dovremo aggiungere un indice type alla tabella.
5 Mi Piace
@Roman, puoi occupartene quando hai un po’ di tempo?
5 Mi Piace
Sto ricevendo molte immagini invisibili nella coda di revisione. Alcune funzionano perfettamente, è un caso su due. Alcune mostrano qualcosa del genere durante l’ispezione e non viene visualizzato nulla:
src="/images/transparent.png" alt="" data-orig-src="upload://fwf1zrfwefWEqGer2W3xz1ed.jpeg"
Accade sia per le istanze che utilizzano una CDN + S3, sia per quelle con archiviazione locale.
1 Mi Piace
Sì, il problema interessa solo i post in coda.
Ho una PR con una correzione in attesa di revisione, quindi le immagini dovrebbero ricomparire a breve.
Ti farò sapere non appena l’avremo unita.
4 Mi Piace
La correzione è ora disponibile su tests-passed e stable.
Tuttavia, persiste un altro problema: le immagini dei post in coda rifiutate non vengono ancora visualizzate nella coda di revisione. Il sistema le rimuove automaticamente, poiché non è necessario mantenerle. Intendiamo sostituirle con un testo che ne spieghi il motivo.
8 Mi Piace
Grazie mille per aver risolto il problema, @Roman!
C’è un’altra cosa che potrebbe essere un bug in tests-passed: Scenario: Accettare un post nella coda di revisione, poi tornare indietro e rifiutarlo. Il post rimarrà elencato e visibile sul sito.
Modifica: i due paragrafi finali di questo commento spiegano anche un’altra possibile problematica relativa ad alcune opzioni della coda di revisione e ai limiti di frequenza a livello di sito: Discourse No Bump - #27
1 Mi Piace
Qualcos’altro che ho notato riguarda l’impostazione ‘gestisci automaticamente le code dopo X giorni’. Ho molti elementi vecchi in alcune code di revisione che sono significativamente più vecchi del valore predefinito di ‘gestisci automaticamente le code dopo X giorni’, ma sembrano non essere gestiti automaticamente. Non sembra che nessuno degli elementi venga gestito automaticamente. Non sono sicuro di stare trascurando qualcosa.
Inoltre, quando ordino la coda di revisione per ‘Creato il (decrescente)’, ottengo un errore 500. Tutti gli altri filtri ‘ordina per’ funzionano correttamente.
1 Mi Piace
Puoi controllare i tuoi log e farci sapere qual è l’errore quando cambi l’ordine di ordinamento?
3 Mi Piace
Grazie @eviltrout, sì, certo. Questo è l’errore che vedo:
ActiveRecord::SubclassNotFound (Il meccanismo di ereditarietà a tabella singola non è riuscito a trovare la sottoclasse: ‘ReviewableAkismetPost’. Questo errore viene generato perché la colonna ‘type’ è riservata per memorizzare la classe nel caso di ereditarietà. Rinomina questa colonna se non intendevi usarla per memorizzare la classe di ereditarietà oppure sovrascrivi Reviewable.inheritance_column per utilizzare un’altra colonna per tale informazione.)
/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’
Nota che il plugin Akismet è stato rimosso da diverso tempo su questo specifico forum.
2 Mi Piace
Ah, quindi è ancora correlato a quello. @Roman sembra che ci possa essere ancora un bug qui legato alla presenza di quei vecchi tipi di oggetto revocabile nel database?
4 Mi Piace