Im Prinzip habe ich mir das schon öfter gewünscht aber ich kann auch die Problematik nachvollziehen.
So eine umfangreiche Löschfunktion hatte ich mal in einem anderen großen Projekt verbaut.
Löschen ist gar nicht einfach und sehr komplex und sollte in Transaktionen (mit Fallback) geschrieben werden.
Als ich damit anfing, hatte ich eine sehr vereinfachte "Löschung" vorgefunden.
Diese gab die Meldung aus, dass "gelöscht" wurde, bevor die SQL an die Datenbank geschickt wurde.
Ob die Datenbank jemals alle Zeilen oder überhaupt irgend etwas löschte, blieb im Dunkeln.
Und so kam es, dass u.a. deswegen die Datenbank voll mit Datenmüll war.
Aber derjenige der Löschte, der war beruhigt, denn er hatte ja die Erfolgsmeldung.
Um beim Beispiel zu bleiben, war die Löschung eins Users mit allen seinen Daten am umfangreichsten.
Das geht dann wie eine Kaskade nach unten zu den letzten Daten, wie bei einem weit verzweigten Wurzelwerk (und manche User können viele Millionen Daten angesammelt haben).
Einfach alles zu löschen bedeutete den Stillstand der Datenbank und somit auch des kompletten Portals.
Ok, als Superduperadmin kann man den SQL Befehl in der DB einfach löschen und das Dingens läuft wieder.
Aber was das Harakiri bewirkte, ist meistens ein Verlust der Abhängigkeiten der Tabellen und Datensätze, weil nicht in jeder Tabelle direkte Zuordnungen zum User enthalten sind (Das dümmste wäre, den User aus der Usertabelle zuerst zu löschen und bei einem Crash dann keine User-Zuordnung mehr zu haben).
Gleiches gibt es auch bei Contenido Zuhauf, man muss sich nur mal die SQLs anschauen, um zu sehen wie viele Abhängigkeiten drin stecken, um an einen Datensatz zu kommen.
Daten ohne Zusammenhänge sind meistens Datenmüll.
Aber finde den Müll erst einmal, wenn die Zeiger auf diese Daten fehlen!
Folglich blieb hier nur übrig, Schritt für Schritt die Daten auf längere Zeit gesehen zu löschen, in kleinen Häppchen, damit sich das System nicht daran verschluckt.
Alle zu löschenden Daten in eine Tabelle packen und diese per Cronjob abarbeiten und jedesmal prüfen, ob die Daten auch wirklich gelöscht wurden und erst dann den Hinweis darauf aus der Löschtabelle löschen.
Falls etwas nicht gelöscht wurde, warum auch immer (auch Server haben mal schlechte Laune), dann musste das protokolliert werden, damit man diese Daten später manuell löschen konnte.
Ich denke, ähnlich wird es auch bei einer Mandanten-Löschung laufen müssen.
Mandanten können ja richtig groß werden und ein einfaches Löschen würde sicher einen normalen Hostingplatz-Server zum Ausbremsen animieren.
"Internal Server Error 500" ist sicher manchen ein Begriff.
Entwickler kann man schnell altern lassen, wenn dann gefordert wird, man möchte gerne eine Papierkorb-Funktion, aus der man alles zurück holen kann, falls man doch nicht löschen wollte...
Mit einer zusätzlichen Spalte in der Tabelle die einen Löschhinweis enthält, könnte man das sehr einfach lösen.
Alles was so markiert wurde, wird nicht angezeigt und irgendwann mal ganz gelöscht.
Aber wer kleine Fehlerchen die sich so einschleichen, kennt, der weiß wie schnell eine komplette Tabelle mit "löschen" ausgezeichnet sein kann oder aber die Daten doch sichtbar werden, weil irgendwann im Code eines Coders vergessen wurde, den Löschhinweis zu berücksichtigen.
Ich bin daher nach wie vor für eine Löschtabelle und dem tatsächlichen Löschen oder Verschieben der Daten.
Das ist aufwändig aber sicher.
Ich vermute mal, ähnliche Gedanken sind dem 4fb Team auch durch den Kopf gegangen.
