L’Admin Toolbox : impersonation, force release, réparations de flows bloqués

L’Admin Toolbox est le chemin d’échappement contrôlé pour les problèmes tenant que l’UI normale ne peut pas résoudre : un tenant, une ligne, un flow bloqué, avec motif obligatoire, activity event et le plus petit rayon d’action possible. Rien là-dedans n’est une version rapide du travail normal. Tout est un bris de glace, avec un registre posé à côté de la vitre.

Impersonation avec write-block

Le plus gros outil. Depuis la page de détail d’un utilisateur sur /admin/users/[slug], le staff plateforme démarre une session impersonated pour voir l’app comme cet utilisateur tenant la voit — plus de ping-pong d’e-mails sur le bouton qui est grisé. Le démarrage exige un motif d’au moins cinq caractères, la session dure 30 minutes, et elle est en lecture seule : pendant l’impersonation, chaque requête mutante est refusée, les server actions refusent d’écrire, et la bannière le dit. Démarrer une nouvelle session révoque automatiquement la précédente. Le début et la fin sont tous deux écrits dans l’activity log avec le motif, si bien qu’un tenant qui demande « est-ce que quelqu’un de la plateforme a regardé notre compte ? » reçoit une ligne, pas une supposition. Les clients trade-in ont leur propre chemin depuis /admin/customers/[id], avec le même motif, la même horloge et le même write-block.

L’unique force-complete

Il existe exactement un force-complete, et il concerne les collections bloquées : une collection coincée dans un statut non terminal affiche sur sa page de détail une trappe d’évacuation réservée à la plateforme, qui la pousse jusqu’à la complétion et écrit l’override dans le journal d’audit. Les receiving sessions, les stages de workflow et les runs de settlement n’ont pas de bouton de ce genre, et c’est voulu ; ils se résolvent par leurs flows normaux, et un bouton de forçage dont personne n’a besoin est un bouton de forçage que quelqu’un finira par presser.

Surfaces admin d’escrow

La confirmation et l’annulation ordinaires d’un dépôt dans /admin/escrow/pending exigent deux platform owners. Les exceptions sont accessibles aux platform owners et au platform staff : annuler un dépôt toujours en attente depuis au moins sept jours avec un motif d’au moins dix caractères, ou approuver la proposition de confirmation d’une autre personne avec un motif d’au moins vingt caractères. /admin/escrow/disputes contient l’examen des litiges. /admin/escrow/force-release est réservé aux platform owners : choisir vendeur, acheteur ou partage, fournir un motif d’au moins trente caractères et répéter le numéro exact de l’escrow. Les parts doivent correspondre au montant total.

Chacune de ces trois corrections enregistre ensemble son état, l’approbation et les écritures éventuelles, l’événement du dossier et l’audit obligatoire. Une erreur laisse l’état précédent intact. Répéter la même instruction avec le même acteur ne crée pas une seconde correction ; les écritures existantes ne sont pas remplacées. Les droits actuels sont revérifiés et une session d’impersonation active bloque l’action. Le motif opérationnel reste dans le dossier. Un déblocage ou remboursement enregistré ne déclenche aucun virement bancaire ; forcer une décision financière ne résout pas automatiquement le fond d’un litige existant.

Sync Blancco, à la demande

La sync Blancco par tenant tourne sur une planification, mais un tenant qui vient de brancher l’intégration ne devrait pas attendre le tic suivant. La carte intégrations sur /admin/organizations/[slug] montre le statut de connexion et la dernière sync, et un bouton « Synchroniser » exécute le même chemin de code avant l’heure.

Utilisateurs échoués et e-mail non vérifié

La page de détail utilisateur est aussi l’établi de récupération. Elle montre le statut de vérification de l’e-mail et l’état du compte, et propose de renvoyer l’invitation ou l’e-mail de vérification, une réinitialisation de mot de passe, une suspension et une réactivation — le tout sans ouvrir d’abord le formulaire de modification. Un utilisateur qui s’est retrouvé sans contexte d’organisation valide est échoué ; le staff plateforme le récupère dans une nouvelle organisation en saisissant un nom et un slug. La suppression de compte est un chemin d’effacement, pas une suppression de ligne, et n’est jamais disponible pour votre propre compte.

Purge du stockage d’un tenant

Le bouton le plus dangereux de /admin/storage est « Purger le stockage », et il est réservé à l’owner ; tout autre rôle plateforme reçoit un refus du serveur et rien n’est touché. La boîte de dialogue charge d’abord un aperçu de exactement ce qui partirait — enregistrements de documents non liés, enregistrements de fichiers manquants et objets orphelins, avec les compteurs — puis demande le nom exact de l’organisation, et n’active le bouton rouge que s’il y a quelque chose à purger et que le nom correspond. Les documents attachés à un enregistrement métier vivant ne sont jamais comptés et jamais supprimés. Le résultat est journalisé en fail-closed avec les compteurs ; si le journal ne peut pas être écrit, la purge ne tourne pas. Il n’y a pas d’annulation, et c’est bien pour cela qu’il y a un aperçu.

audit_events est append-only

La table audit_events a des triggers de base de données qui rejettent UPDATE et DELETE, et chaque ligne est chaînée à la précédente par un hash inviolable, si bien qu’un trou ou une réécriture se voit. De nouvelles lignes peuvent être insérées ; l’originale reste. L’Admin Toolbox peut réparer ce qui est cassé. Elle ne peut pas faire le ménage dans ce qui a été enregistré.