L’admin toolbox: force-complete, impersonation, stuck-flow fixes

L’Admin Toolbox est le chemin d’escape contrôlé pour les problèmes tenant que l’UI normale ne peut pas résoudre : un tenant, une row, un flow bloqué, avec audit, raison obligatoire et blast radius minimale.

Force-complete endpoints

Des flows opérationnels précis ont une escape-hatch force-complete exposée dans l’UI platform admin : une receiving session qui ne se ferme pas à cause d’un stale lock, une workflow stage qui doit avancer alors qu’un critère manque, un settlement run qui a aborted à mi-chemin. Chaque force-complete écrit son propre audit event avec la raison, l’actor et les affected rows. Les endpoints n’existent pas pour l’usage général ; ce sont les chemins “somebody needs to break the glass”.

Trois escape-hatches pour escrows bloqués

Les escrows peuvent se bloquer de trois façons précises : deposit confirmed mais funds non arrivés (payment-side mismatch), goods received mais ship-guard non levé (ship-event-side mismatch), release ready mais settlement row non écrite (settlement-side mismatch). Chacun a son propre admin button sous /admin/escrow avec un confirmation prompt qui détaille exactement ce qui sera changé — pas d’actions composées cachées derrière un seul clic.

Manual Blancco sync trigger

Le sync Blancco par tenant tourne sur un cron, mais si un tenant vient de configurer l’intégration ou vient d’avoir un bulk-import qui demande une attention immédiate, un bouton admin déclenche le sync on demand. Le trigger respecte les mêmes rate-limit et batching que le cron — c’est le même code path, simplement avant le prochain run planifié.

Email-vérification + stranded-signup recovery

Quand un tenant admin s’inscrit mais ne reçoit jamais l’e-mail de vérification, /admin/users expose le verification status et propose un re-send. Les stranded signups (démarrés mais jamais complétés) apparaissent dans /admin/onboarding avec l’option de clear manuellement ou de re-send le welcome flow.

Subscription-status override

Quand le subscription_status d’un tenant diverge du statut reporté par le billing provider (rare, mais cela arrive — webhook manqué, manual cancel), /admin/billing propose un champ override direct avec une reason note obligatoire ; l’override est audit-logged et le billing provider est réconcilié au prochain webhook.

Impersonation with write-block

Le plus gros outil. /admin/impersonate permet au platform staff de se connecter comme un tenant user (read-only) pour investiguer ce qu’il voit sans échange d’e-mails. Le middleware intercepte les mutating HTTP methods (POST, PUT, PATCH, DELETE) sur les sessions impersonated et retourne un 403 avec l’erreur “impersonation is read-only”. Le session tracking écrit chaque page visitée par l’impersonator dans l’activity log — donc un tenant qui demande “quelqu’un de la plateforme a-t-il regardé nos données ?” reçoit une row, pas une supposition.

audit_events append-only au niveau trigger

La table audit_events a des database triggers qui refusent UPDATE et DELETE. Même un admin avec accès database élevé ne peut pas réécrire l’historique en silence. De nouvelles rows peuvent être insérées (une correction avec référence à l’original event), mais la row originale reste. L’Admin Toolbox peut réparer ce qui est cassé ; elle ne peut pas nettoyer ce qui a été enregistré.