Un rapido aggiornamento sullo stato di avanzamento dopo aver analizzato il codice esistente per l’eliminazione permanente:
Ho scoperto che Discourse dispone già del comportamento di eliminazione in blocco necessario in questo caso. Quando il primo post viene eliminato permanentemente, PostDestroyer può già eliminare in modo ricorsivo e permanente i post rimanenti nel topic. La restrizione risiede principalmente nei controlli di autorizzazione e policy, che attualmente richiedono che gli altri post vengano eliminati permanentemente in precedenza.
Di conseguenza, ho abbandonato l’enum a livello di sito che avevo suggerito in precedenza e ho realizzato un’implementazione funzionante che utilizza un modello di opt-in più conservativo:
- l’impostazione esistente
can_permanently_deleterimane l’interruttore principale - è presente un ulteriore controllo a livello di operatore, nascosto e disabilitato per impostazione predefinita
- quando entrambi sono abilitati, ogni amministratore può optare individualmente per questa funzione nelle Preferenze → Interfaccia
- l’opt-in di un amministratore non modifica il comportamento per gli altri amministratori
- la disattivazione del controllo nascosto ripristina immediatamente il comportamento esistente a livello globale
- la conferma dell’eliminazione permanente esistente e le altre misure di sicurezza restano invariate
L’impostazione è attualmente etichettata come:
Consenti all’eliminazione permanente del topic di eliminare tutti i post
con la seguente spiegazione:
Quando si elimina permanentemente un topic, elimina anche in modo permanente tutti i post rimanenti, anziché richiederne l’eliminazione permanente individuale.
Ho aggiunto test di policy/sicurezza sul backend, copertura dei controller che conferma che il topic e tutti i post rimanenti vengono effettivamente eliminati in modo permanente, copertura di serializer/API e test di accettazione frontend per la visibilità e il salvataggio dell’impostazione. Questi test sono superati.
Sto anche valutando la registrazione delle modifiche a questo opt-in per amministratore nei registri delle azioni dello staff (Staff Action Logs), poiché l’abilitazione di una modalità di eliminazione più distruttiva sembra meritevole di essere un evento di audit con timestamp.
Pubblicherò la PR su GitHub una volta completato questo aspetto e la revisione finale.