Ein kurzes Fortschrittsupdate, nachdem ich mich in den vorhandenen Code für die permanente Löschung vertieft habe:
Ich habe festgestellt, dass Discourse bereits das tatsächliche Verhalten für die Massenlöschung besitzt, das hier benötigt wird. Wenn der erste Beitrag dauerhaft gelöscht wird, kann PostDestroyer die verbleibenden Beiträge im Thema bereits rekursiv dauerhaft löschen. Die Einschränkung liegt hauptsächlich in den Berechtigungs- und Policy-Prüfungen, die derzeit verlangen, dass die anderen Beiträge zuerst dauerhaft gelöscht werden müssen.
Ich habe mich daher von der site-weiten Enumeration verabschiedet, die ich oben vorgeschlagen habe, und habe eine funktionierende Implementierung mit einem konservativeren Opt-in-Modell erstellt:
- Die bestehende Einstellung
can_permanently_deletebleibt der Hauptschalter - Es gibt ein zusätzliches, standardmäßig deaktiviertes, verborgenes Gate auf Operator-Ebene
- Wenn beide aktiviert sind, kann sich jeder Administrator unter Einstellungen → Oberfläche individuell opt-in
- Wenn sich ein Administrator opt-in, ändert sich das Verhalten für keinen anderen Administrator
- Das Deaktivieren des verborgenen Gates stellt das bestehende Verhalten sofort global wieder her
- Die bestehende Bestätigung für die permanente Löschung und andere Sicherheitsvorkehrungen bleiben in Kraft
Die Einstellung ist derzeit wie folgt beschriftet:
Erlaube, dass die permanente Löschung eines Themas alle Beiträge löscht
mit der Erklärung:
Lösche bei der permanenten Löschung eines Themas auch alle verbleibenden Beiträge, anstatt sie einzeln dauerhaft löschen zu müssen.
Ich habe Backend-Policy-/Sicherheitstests, Controller-Abdeckung zur Bestätigung, dass das Thema und alle verbleibenden Beiträge tatsächlich dauerhaft entfernt werden, Serializer-/API-Abdeckung und Frontend-Akzeptanztests für die Sichtbarkeit und das Speichern der Einstellung hinzugefügt. Diese bestehen.
Ich überlege auch, Änderungen an diesem Administrator-spezifischen Opt-in in den Staff Action Logs zu protokollieren, da die Aktivierung eines destruktiveren Löschmodus als zeitgestempeltes Audit-Ereignis sinnvoll erscheint.
Ich werde den GitHub-PR posten, sobald ich das und die finale Überprüfung abgeschlossen habe.