Trade-In account impersonation: investiguer côté customer
Comment impersonation se scope a la surface trade-in customer, pourquoi elle vit sur sa propre page detail M020, et ce que le scoping profile/notifications empeche.
Le module trade-in a son propre auth shell, sa propre RLS et son propre user model — séparés de l’app opérateur pour de bonnes raisons. Cela veut dire que l’impersonation d’un trade-in customer nécessite son propre chemin ; l’outil d’impersonation côté opérateur n’atteint pas la customer surface. La page /admin/trade-in-accounts/[id] (M020 detail) est l’endroit où ce chemin vit.
Ce qu’il fait
Depuis la M020 detail page, un platform-staff user choisit un trade-in account et démarre une session impersonated pour lui. La session ouvre le portail customer-facing comme ce client le verrait : ses pickup requests, ses bids, ses awarded ITADs, ses invoices, ses notifications. Read-only — le même write-block que l’impersonation côté opérateur s’applique ici aussi.
Pourquoi scoped à M020
Parce que les trade-in customers et les operator users vivent dans des tables différentes, avec des join paths différents vers les companies. Le flow impersonate côté opérateur suppose des operator-tenant relationships ; le côté trade-in suppose des customer-account relationships. Les câbler dans un seul outil aurait été un fouillis de conditionals — une page séparée pour chacun est plus propre, et la M020 detail page est de toute façon la maison naturelle de l’admin trade-in account.
Profile + notifications scoping
Le profile component et le notifications component lisent explicitement l’impersonated company quand un impersonation context est actif. Le platform-staff user voit donc ce que le client voit : le profil du customer, ses notifications, et aucune décoration de son propre compte.
Banner countdown
L’impersonation affiche une banner en haut : “impersonating {company} — read-only — exit in {time}.” Le countdown utilise un timestamp dérivé serveur, donc la banner reste stable au page load et le temps read-only restant reste clair.
Audit log, end-to-end
Chaque page visitée par l’impersonator écrit dans l’activity log avec l’action “impersonate-view: /trade-in/{path}” et le user_id de l’impersonator. La fin de session écrit un event “impersonate-end” avec la duration. L’impersonated customer peut demander le log via son account, et la plateforme peut produire la réponse “quelqu’un de la plateforme a-t-il regardé nos données, quand et quoi ?” avec des rows, pas des paragraphes.