Trade-In account impersonation: onderzoeken vanaf de klantzijde
Hoe impersonation scoped is naar het trade-in-klantportaal, waarom het vanaf het trade-in-accountdetail vertrekt, en wat het scopen van profiel en notificaties naar het bekeken bedrijf voorkomt.
De trade-in-module heeft zijn eigen auth shell, eigen RLS en eigen usermodel — los van de operator-app, om goede redenen. Dat betekent dat een trade-in-klant impersoneren een eigen pad nodig heeft; de impersonation tool aan operatorzijde bereikt het klantvlak niet. Het trade-in-accountdetail op /admin/customers/[id] is waar dat pad leeft.
Wat het doet
Vanaf het accountdetail start een platform-staff-gebruiker een geïmpersonateerde sessie voor dat klantbedrijf. De knop vraagt eerst een supportreden van minstens vijf tekens en opent daarna het klantportaal zoals dat account het zou zien: hun ophaalaanvragen, hun bids, hun awarded ITADs, hun facturen, hun notificaties. Read-only — dezelfde write-block als aan operatorzijde geldt hier, en de melding in het portaal zegt precies dat: “Alleen lezen · sessie van 30 min · audit-gelogd”.
Waarom een aparte pagina
Omdat trade-in-klanten en operatorgebruikers in verschillende tabellen leven, met verschillende joinpaden naar bedrijven. De flow aan operatorzijde gaat uit van operator-tenantrelaties; de trade-in-kant gaat uit van klant-accountrelaties. Die twee in één tool bedraden zou een brij van conditionals geworden zijn — een aparte ingang per kant is properder, en het accountdetail is toch al de plek waar trade-in-accountsupport gebeurt: bedrijfsgegevens, goedkeuringsdrempels, leden, recente ophaalaanvragen en de collections die eraan hangen.
Profiel en notificaties scopen
De profielcomponent en de notificatiecomponent lezen expliciet het geïmpersonateerde bedrijf zodra er een impersonation-context actief is. Zo blijft de platform-staff-gebruiker op het vlak van de klant: het profiel van de klant, de notificaties van de klant, geen decoratie van het staff-account. De profielpagina van het portaal volgt de bekijk-dan-bewerk-regel van de app — een klant bewerkt er voornaam, achternaam en telefoon en wijzigt er zijn wachtwoord, terwijl e-mail en portaalrol voor iedereen read-only blijven — en onder impersonation is de hele pagina read-only, zodat een supportmedewerker nooit per ongeluk het profiel van een klant overschrijft. Een viewer in het portaal ziet geen knop “Nieuwe aanvraag” en krijgt uitleg in het portaal wanneer hij de aanmaakpagina rechtstreeks opent, en de impersonator ziet exact hetzelfde portaal als de klant, uitleg inbegrepen.
Bannercountdown
Impersonation toont bovenaan een banner met de bedrijfsnaam, de read-only-melding en de resterende tijd. De countdown wordt afgeleid van de vervaltijd op de server, zodat hij stabiel blijft over page loads heen en de resterende sessietijd nooit een gok is.
Audit log
De sessie starten schrijft een activity event met de staff-gebruiker, het klantaccount en de reden; stoppen schrijft er nog een. Sessies verlopen vanzelf na 30 minuten, en een nieuwe starten trekt de vorige in. Wanneer een klant vraagt of iemand van het platform naar zijn account gekeken heeft, antwoordt het platform met rijen: wie, welk account, wanneer het begon, wanneer het stopte, en waarom.