Une mise à jour rapide sur l’avancement après avoir creusé dans le code existant de suppression définitive :
J’ai constaté que Discourse dispose déjà du comportement de suppression en masse nécessaire ici. Lorsque le premier message est définitivement détruit, PostDestroyer peut déjà détruire de manière récursive et définitive les messages restants du sujet. La restriction réside principalement dans les vérifications de permissions/politiques, qui exigent actuellement que les autres messages soient d’abord supprimés définitivement.
J’ai donc abandonné l’énumération à l’échelle du site que je proposais ci-dessus et ai mis en place une implémentation fonctionnelle utilisant un modèle d’opt-in plus conservateur :
- le paramètre existant
can_permanently_deletereste l’interrupteur principal - il existe une porte d’accès supplémentaire au niveau opérateur, cachée et désactivée par défaut
- lorsque les deux sont activés, chaque administrateur peut individuellement s’abonner sous Préférences → Interface
- le fait qu’un administrateur s’abonne ne modifie pas le comportement pour les autres administrateurs
- la désactivation de la porte d’accès cachée restaure immédiatement le comportement existant à l’échelle globale
- la confirmation de suppression définitive existante et les autres mesures de sécurité restent en place
La préférence est actuellement étiquetée :
Autoriser la suppression définitive du sujet à supprimer tous les messages
avec l’explication :
Lors de la suppression définitive d’un sujet, supprimer également définitivement tous les messages restants au lieu d’exiger qu’ils soient supprimés définitivement un par un.
J’ai ajouté des tests de politique/sécurité côté serveur, une couverture du contrôleur confirmant que le sujet et tous les messages restants sont effectivement supprimés définitivement, une couverture du sérialiseur/API, et des tests d’acceptation front-end pour la visibilité et l’enregistrement de la préférence. Ceux-ci passent.
Je regarde également comment enregistrer les modifications de cet opt-in par administrateur dans les journaux d’actions du personnel, car l’activation d’un mode de suppression plus destructeur semble mériter d’être un événement d’audit horodaté.
Je posterai la PR GitHub une fois que j’aurai terminé cela et la revue finale.