Personnes

Les inventaires (utilisateurs, organisations, boutiques), une fiche pour chaque ligne, et les mandats.

Le modèle de tenant, en un paragraphe

Un utilisateur peut appartenir à plusieurs organisations. Une organisation possède les boutiques, l'abonnement, le ledger de crédits et les conversations. Presque tout dans le produit est rattaché à une organisation, donc « ce client » est presque toujours une org, pas un utilisateur.

Les rôles et la surcharge de permissions par membre sont décrits pour les clients dans Organisations et rôles. Le même modèle, lu depuis le panel.

Deux actions que vous ne pouvez pas vraiment annuler

Bannir un utilisateur met fin à ses sessions. Toute org dont il est le seul propriétaire devient inadministrable par ses propres membres : vérifiez la propriété avant de bannir, pas après.

Supprimer une boutique efface ses données en cascade : connexions, scans, intelligence, faits de mémoire. La ligne disparaît ; Shopify n'en sait rien et garde le jeton d'accès qu'il avait, jusqu'à ce que celui-ci soit révoqué. Révoquez d'abord (POST /api/integrations/shopify/revoke), supprimez ensuite.

Modifier un plan à la main

C'est possible, et cela ne passe pas par Stripe. Vous écrivez l'état local de l'abonnement, pas la relation de facturation. Le cron nocturne reconcile-stripe compare les deux et corrigera une modification locale avec laquelle Stripe n'est pas d'accord, ce qui est le comportement voulu, et aussi la raison pour laquelle un plan posé à la main peut revenir en arrière sans bruit.

Offrez un plan délibérément par le chemin des grants, pour qu'il porte une échéance sur laquelle le cron expire-grants peut agir. Une ligne modifiée à la main n'a pas d'échéance, et rien ne la rétrograde.

À quoi servent les fiches

Diagnostiquer « le client dit X mais le produit dit Y ». La fiche organisation montre l'abonnement, les membres, les boutiques et le solde de crédits côte à côte, ce qui suffit en général pour voir lequel des trois est désynchronisé.