Impersonation d’un compte Trade-In : enquêter depuis le côté client

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. Ce qui veut dire que l’impersonation d’un client trade-in a besoin de son propre chemin ; l’outil d’impersonation côté opérateur n’atteint pas la surface client. Le détail du compte trade-in sur /admin/customers/[id] est l’endroit où ce chemin vit.

Ce qu’elle fait

Depuis le détail du compte, un utilisateur du staff plateforme démarre une session impersonated pour cette company cliente. Le bouton demande d’abord un motif de support d’au moins cinq caractères, puis ouvre le portail client tel que ce compte le verrait : ses pickup requests, ses bids, ses awarded ITADs, ses factures, ses notifications. Lecture seule — le même write-block que l’impersonation côté opérateur s’applique, et la mention dans le portail le dit exactement : « Lecture seule · session 30 min · journalisée ».

Pourquoi une page séparée

Parce que les clients trade-in et les utilisateurs opérateur vivent dans des tables différentes, avec des chemins de jointure différents vers les companies. Le flow côté opérateur suppose des relations operator-tenant ; le côté trade-in suppose des relations customer-account. Câbler les deux dans un seul outil aurait donné un fouillis de conditions — une entrée séparée pour chacun est plus propre, et le détail du compte est de toute façon l’endroit où se fait le support des comptes trade-in : détails de la company, seuils d’approbation, membres, pickup requests récentes et les collections qui en découlent.

Scoping du profil et des notifications

Le composant profil et le composant notifications lisent explicitement la company impersonated quand un contexte d’impersonation est actif. Cela garde l’utilisateur du staff plateforme sur la surface du client : le profil du client, les notifications du client, aucune décoration venue du compte staff. La page profil du portail suit la règle voir-puis-modifier de l’app — un client y modifie prénom, nom et téléphone et change son mot de passe, tandis que l’e-mail et le rôle portail restent en lecture seule pour tout le monde — et sous impersonation la page entière est en lecture seule, de sorte qu’un agent de support ne peut jamais écraser par accident le profil d’un client. Un viewer dans le portail ne voit pas de bouton « Nouvelle demande » et reçoit une explication dans le portail s’il ouvre la page de création directement, et celui qui fait l’impersonation voit le même portail que le client, explications comprises.

Compte à rebours de la bannière

L’impersonation affiche une bannière en haut, avec le nom de la company, la mention lecture seule et le temps restant. Le compte à rebours dérive de l’expiration côté serveur : il reste donc stable d’un chargement de page à l’autre, et le temps de session restant n’est jamais une supposition.

Journal d’audit

Le démarrage de la session écrit un activity event avec l’utilisateur staff, le compte client et le motif ; l’arrêt en écrit un autre. Les sessions expirent d’elles-mêmes au bout de 30 minutes, et en démarrer une nouvelle révoque la précédente. Quand un client demande si quelqu’un de la plateforme a regardé son compte, la plateforme répond par des lignes : qui, quel compte, quand ça a commencé, quand ça s’est terminé, et pourquoi.