Trade-In Account Impersonation: Investigating From The Customer’s Side
How impersonation scopes to the trade-in customer surface specifically, why it lives on its own M020 detail page, and what scoping the 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 impersonation of a trade-in customer needs its own path; the operator-side impersonation tool doesn’t reach the customer surface. The /admin/trade-in-accounts/[id] page (M020 detail) is where that path lives.
What it does
From the M020 detail page, a platform-staff user picks a trade-in account and starts an impersonated session for it. The session opens the customer-facing portal as that customer would see it: their pickup requests, their bids, their awarded ITADs, their invoices, their notifications. Read-only — the same write-block from the operator-side impersonation applies here too.
Why scoped to M020
Because trade-in customers and operator users live in different tables, with different join paths to companies. The operator-side impersonate 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 page for each is cleaner, and the M020 detail page is the natural home for trade-in account admin in any case.
Profile + 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, and no decoration from the staff account.
Banner countdown
Impersonation surfaces a banner across the top: “impersonating {company} — read-only — exit in {time}.” The countdown is based on a server-derived timestamp, so the banner stays stable on page load and the remaining read-only session time is clear.
Audit log, end-to-end
Every page the impersonator visits writes to the activity log with the action “impersonate-view: /trade-in/{path}” and the impersonator’s user_id. End of session writes a “impersonate-end” event with the duration. The impersonated customer can request the log through their account, and the platform can produce the “did somebody from the platform look at our data, when, and at what” answer with rows, not paragraphs.