Trade-In Account Impersonation: Investigating From The Customer’s Side
How impersonation scopes to the trade-in customer portal, why it starts from the trade-in account detail, and what scoping profile and notifications to the impersonated company prevents.
The trade-in module has its own auth shell, its own RLS and its own user model — separate from the operator app for good reasons. Which means impersonating a trade-in customer needs its own path; the operator-side impersonation tool does not reach the customer surface. The trade-in account detail at /admin/customers/[id] is where that path lives.
What it does
From the account detail, a platform-staff user starts an impersonated session for that customer company. The button first asks for a support reason of at least five characters, then opens the customer portal as that account would see it: their pickup requests, their bids, their awarded ITADs, their invoices, their notifications. Read-only — the same write-block as operator-side impersonation applies, and the portal notice says exactly that: “Read-only · 30-min session · audit-logged”.
Why a separate page
Because trade-in customers and operator users live in different tables, with different join paths to companies. The operator-side flow assumes operator-tenant relationships; the trade-in side assumes customer-account relationships. Wiring the two into one tool would have been a mess of conditionals — a separate entry for each is cleaner, and the account detail is where trade-in account support happens anyway: company details, approval thresholds, members, recent pickup requests and the collections hanging off them.
Profile and notifications scoping
The profile component and the notifications component read the impersonated company explicitly when an impersonation context is active. That keeps the platform-staff user on the customer’s surface: the customer’s profile, the customer’s notifications, no decoration from the staff account. The portal’s own profile page follows the app’s view-then-edit rule — a customer edits first name, last name and phone and changes their password there, while e-mail and portal role stay read-only for everyone — and under impersonation the whole page is read-only, so a support agent can never overwrite a customer’s profile by accident. A viewer in the portal sees no “New request” button and gets an in-portal explanation if they open the create page directly, and the impersonator sees the same portal the customer does, explanations included.
Banner countdown
Impersonation surfaces a banner across the top with the company name, the read-only notice and the time left. The countdown is derived from the server-side expiry, so it stays stable across page loads and the remaining session time is never a guess.
Audit log
Starting the session writes an activity event with the staff user, the customer account and the reason; stopping it writes another. Sessions expire on their own after 30 minutes, and starting a new one revokes the previous. When a customer asks whether somebody from the platform looked at their account, the platform answers with rows: who, which account, when it started, when it ended, and why.