Die Admin Toolbox: Impersonation, Force Release, Fixes für hängende Flows
Buttons mit Pflichtbegründung, engem Blast Radius und einer Audit-Zeile für die Tenant-Probleme, die die normale UI nicht löst.
Die Admin Toolbox ist der kontrollierte Fluchtweg für Tenant-Probleme, die sich in der normalen UI nicht lösen lassen: ein Tenant, eine Zeile, ein hängender Flow, mit Pflichtbegründung, Audit-Event und kleinstmöglichem Blast Radius. Nichts davon ist eine schnellere Version der normalen Arbeit. Alles davon ist ein Break-Glass-Pfad mit einem Logbuch neben der Scheibe.
Impersonation mit Schreibsperre
Das größte Werkzeug. Von der Detailseite eines Users unter /admin/users/[slug] startet Platform Staff eine impersonierte Session und sieht die App so, wie dieser Tenant-User sie sieht — kein E-Mail-Pingpong darüber, welcher Button ausgegraut ist. Der Start verlangt eine Begründung von mindestens fünf Zeichen, die Session dauert 30 Minuten und ist read-only: Während der Impersonation wird jeder schreibende Request abgewiesen, Server Actions schreiben nicht, und das Banner sagt genau das. Eine neue Session widerruft automatisch die vorherige. Start und Stopp werden beide mit der Begründung ins Activity-Log geschrieben, sodass ein Tenant, der fragt, ob jemand von der Plattform in sein Konto geschaut hat, eine Zeile bekommt und keine Vermutung. Trade-in-Kunden haben ihren eigenen Weg über /admin/customers/[id], mit derselben Begründung, derselben Uhr und derselben Schreibsperre.
Das eine Force-Complete
Es gibt genau ein Force-Complete, und das gilt für hängende Collections: Eine Collection, die in einem nicht-terminalen Status festsitzt, zeigt auf ihrer Detailseite einen platform-only Notausgang, der sie auf Abschluss schiebt und den Override ins Audit-Log schreibt. Receiving Sessions, Workflow Stages und Settlement-Läufe haben absichtlich keinen solchen Button; sie lösen sich über ihre normalen Flows, und ein Force-Button, den niemand braucht, ist ein Force-Button, den irgendwann jemand drückt.
Escrow-Flächen im Admin
Die reguläre Einzahlungsbestätigung und Stornierung unter /admin/escrow/pending erfordern zwei Platform Owner. Ausnahmen sind für Platform Owner und Platform Staff verfügbar: eine seit mindestens sieben Tagen ausstehende Einzahlung mit mindestens zehn Zeichen Begründung stornieren oder den Bestätigungsvorschlag einer anderen Person mit mindestens zwanzig Zeichen Begründung genehmigen. /admin/escrow/disputes enthält die Streitfallprüfung. /admin/escrow/force-release ist ausschließlich für Platform Owner: Verkäufer, Käufer oder Aufteilung wählen, mindestens dreißig Zeichen Begründung angeben und die genaue Escrow-Nummer wiederholen. Die Teilbeträge müssen den Gesamtbetrag ergeben.
Jede dieser drei Verwaltungskorrekturen speichert Status, gegebenenfalls Genehmigung und Buchungen, Dossierereignis und verpflichtendes Audit gemeinsam. Bei einem Fehler bleibt der vorherige Zustand erhalten. Dieselbe Anweisung durch denselben Akteur erzeugt keine zweite Korrektur; vorhandene Buchungen werden nicht überschrieben. Die aktuellen Plattformrechte werden erneut geprüft, und eine aktive Impersonationssitzung blockiert die Aktion. Die operative Begründung bleibt im Dossier. Eine erfasste Freigabe oder Rückerstattung löst keine Banküberweisung aus; eine erzwungene finanzielle Entscheidung klärt einen bestehenden Streitfall nicht automatisch inhaltlich.
Blancco-Sync auf Zuruf
Der Blancco-Sync pro Tenant läuft nach Zeitplan, aber ein Tenant, der die Integration gerade erst verbunden hat, sollte nicht auf den nächsten Takt warten. Die Integrationskarte auf /admin/organizations/[slug] zeigt Verbindungsstatus und letzten Sync, und ein Button „Jetzt syncen“ startet denselben Codepfad vorzeitig.
Gestrandete User und unbestätigte E-Mails
Die User-Detailseite ist auch die Werkbank für Wiederherstellungen. Sie zeigt den Verifizierungsstatus der E-Mail und den Kontostatus und bietet das erneute Senden von Einladung oder Bestätigungsmail, einen Passwort-Reset, Sperren und Reaktivieren — alles, ohne vorher das Bearbeitungsformular zu öffnen. Ein User, der ohne funktionierenden Organisationskontext dasteht, ist gestrandet; Platform Staff holt ihn in eine neue Organisation zurück, indem sie einen Namen und einen Slug eingibt. Ein Konto zu löschen ist ein Erasure-Pfad, kein Zeilenlöschen, und für das eigene Konto nie verfügbar.
Purge des Tenant-Storage
Der gefährlichste Button auf /admin/storage heißt „Speicher löschen“, und er ist owner-only; jede andere Platform-Rolle bekommt vom Server eine Absage, und nichts wird angefasst. Der Dialog lädt zuerst eine Vorschau dessen, was tatsächlich verschwinden würde — nicht verknüpfte Dokument-Records, Records ohne Datei und verwaiste Objekte, mit Zählern —, fragt dann nach dem exakten Organisationsnamen und aktiviert den roten Button erst, wenn es etwas zu löschen gibt und der Name stimmt. Dokumente, die an einem lebenden Geschäftsrecord hängen, werden nie mitgezählt und nie entfernt. Das Ergebnis wird fail-closed protokolliert, mit den Zählern; lässt sich das Log nicht schreiben, läuft der Purge nicht. Es gibt kein Undo, und genau deshalb gibt es die Vorschau.
audit_events ist append-only
Die Tabelle audit_events hat Datenbanktrigger, die UPDATE und DELETE abweisen, und jede Zeile ist mit einem manipulationssicheren Hash an die vorherige gekettet, sodass eine Lücke oder eine Umschrift auffällt. Neue Zeilen lassen sich einfügen; das Original bleibt. Die Admin Toolbox kann reparieren, was kaputt ist. Aufräumen, was protokolliert wurde, kann sie nicht.