Trade-in-Account-Impersonation: aus Kundensicht untersuchen

Das Trade-in-Modul hat seine eigene Auth Shell, seine eigene RLS und sein eigenes User-Modell — aus guten Gründen getrennt von der Operator-App. Was bedeutet, dass die Impersonation eines Trade-in-Kunden einen eigenen Weg braucht; das Impersonation-Tool auf Operator-Seite erreicht die Kundenfläche nicht. Das Trade-in-Account-Detail unter /admin/customers/[id] ist der Ort, an dem dieser Weg liegt.

Was es tut

Vom Account-Detail aus startet ein Platform-Staff-User eine impersonierte Session für dieses Kundenunternehmen. Der Button fragt zuerst nach einer Supportbegründung von mindestens fünf Zeichen und öffnet dann das Kundenportal so, wie dieser Account es sehen würde: seine Pickup Requests, seine Gebote, seine Awarded ITADs, seine Invoices, seine Notifications. Read-only — es gilt dieselbe Schreibsperre wie bei der Impersonation auf Operator-Seite, und der Hinweis im Portal sagt genau das: „Nur Lesen · 30-Min.-Sitzung · audit-geloggt“.

Warum eine eigene Seite

Weil Trade-in-Kunden und Operator-User in unterschiedlichen Tabellen leben, mit unterschiedlichen Join-Pfaden zu Unternehmen. Der Flow auf Operator-Seite nimmt Operator-Tenant-Beziehungen an; die Trade-in-Seite nimmt Kunde-Account-Beziehungen an. Beides in ein Tool zu verdrahten wäre ein Gestrüpp aus Bedingungen geworden — ein eigener Einstieg pro Seite ist sauberer, und das Account-Detail ist ohnehin der Ort, an dem Support für Trade-in-Accounts stattfindet: Unternehmensdaten, Freigabeschwellen, Mitglieder, jüngste Pickup Requests und die daran hängenden Collections.

Scoping von Profil und Notifications

Die Profilkomponente und die Notifications-Komponente lesen das impersonierte Unternehmen explizit, sobald ein Impersonation-Kontext aktiv ist. Das hält den Platform-Staff-User auf der Fläche des Kunden: dessen Profil, dessen Notifications, keine Dekoration aus dem Staff-Konto. Die Profilseite des Portals folgt der App-Regel „erst ansehen, dann bearbeiten“ — ein Kunde ändert dort Vorname, Nachname und Telefonnummer und setzt sein Passwort, während E-Mail und Portal-Rolle für alle read-only bleiben —, und unter Impersonation ist die ganze Seite read-only, sodass ein Support-Mitarbeiter das Profil eines Kunden nie versehentlich überschreiben kann. Ein Viewer im Portal sieht keinen Button „Neue Anfrage“ und bekommt eine Erklärung im Portal, wenn er die Anlegeseite direkt öffnet, und der Impersonierende sieht dasselbe Portal wie der Kunde, Erklärungen inklusive.

Countdown im Banner

Die Impersonation zeigt oben ein Banner mit dem Unternehmensnamen, dem Read-only-Hinweis und der verbleibenden Zeit. Der Countdown leitet sich aus dem serverseitigen Ablauf ab, bleibt also über Seitenwechsel hinweg stabil, und die restliche Sessionzeit ist nie eine Schätzung.

Audit-Log

Der Start der Session schreibt ein Activity-Event mit dem Staff-User, dem Kundenaccount und der Begründung; das Beenden schreibt ein weiteres. Sessions laufen nach 30 Minuten von selbst ab, und eine neue widerruft die vorherige. Wenn ein Kunde fragt, ob jemand von der Plattform in sein Konto geschaut hat, antwortet die Plattform mit Zeilen: wer, welcher Account, wann es anfing, wann es endete, und warum.