Aller au contenu principal

Provisioning d'une organisation

Processus de création d'une nouvelle organisation sur la plateforme.

Prérequis​

  • Permission organization.manage (rôle plateforme administrateur)
  • Un slug et un short_code uniques

1. Validation du slug​

Le slug est converti en nom de schéma via tenant_schema_name() : il ne peut contenir que des lettres minuscules, des chiffres et des tirets, et les tirets deviennent des underscores. Le préfixe du schéma est tenant_.

SlugSchéma généréValide ?
cours-lumieretenant_cours_lumiere✅
acme-corptenant_acme_corp✅
ecole2025tenant_ecole2025✅
2eme-ecoletenant_2eme_ecole✅ (chiffres autorisés)
Cours Lumière—❌ (majuscules, espaces, accents)
cours_lumiere—❌ (underscore non autorisé)

2. Appel API​

POST /api/v1/admin/system/organizations
Authorization: Bearer {admin_token}
Content-Type: application/json

{
  "slug": "cours-lumiere",
  "short_code": "CL",
  "name": "Cours Lumière",
  "legal_name": "École Cours Lumière SARL",
  "contact_email": "admin@courslumiere.tg",
  "contact_phone": "+22890123456",
  "card_range_start": 1,
  "card_range_end": 99999
}
ChampRequisDescription
slugOuiIdentifiant unique (minuscules, chiffres, tirets)
short_codeOuiCode court 2-5 caractères (préfixe des codes publics)
nameOuiNom d'affichage
legal_nameNonRaison sociale
contact_emailNonEmail de contact
contact_phoneNonTéléphone
card_range_startNonDébut plage de numéros (défaut 1)
card_range_endNonFin plage de numéros (défaut 99999)
Pas d'admin N1 automatique

Il n'existe pas de champ admin_email : les utilisateurs de l'organisation (dont le premier gestionnaire) se créent ensuite via POST /admin/org/users.

3. Processus interne​

sequenceDiagram
    participant API
    participant PG

    API->>PG: INSERT INTO public.organizations (status: active, currency: XOF)
    API->>PG: CREATE SCHEMA tenant_cours_lumiere
    API->>PG: Appliquer les migrations tenant (tables, fonctions, vues)
    API->>PG: seed_tenant_roles()

    Note over PG: 5 rôles système N1 (is_system_role = true)
    API->>PG: INSERT roles: gestionnaire, superviseur, caissier, vendeur, porteur
    Note over PG: Assignation des permissions par rôle
    API->>PG: INSERT role_permissions (...)

Le provisioning :

  1. Enregistre l'organisation dans public.organizations (statut active, devise XOF, seuil d'anomalie 30000).
  2. Crée le schéma tenant_{slug} et applique les migrations tenant.
  3. Appelle seed_tenant_roles() pour créer les 5 rôles système et leur assigner leurs permissions par défaut.
  4. Configure la notification_config par défaut (email activé, routage anomaly_detected → email).

4. Vérification​

-- Schéma créé
SELECT schema_name FROM information_schema.schemata
WHERE schema_name = 'tenant_cours_lumiere';

-- Rôles seedés
SELECT name, is_system_role FROM public.roles
WHERE organization_id = (SELECT id FROM public.organizations WHERE slug = 'cours-lumiere');

Attendu : 5 rôles (gestionnaire, superviseur, caissier, vendeur, porteur).

Rollback​

DROP SCHEMA tenant_cours_lumiere CASCADE;
DELETE FROM public.roles
WHERE organization_id = (SELECT id FROM public.organizations WHERE slug = 'cours-lumiere');
DELETE FROM public.organizations WHERE slug = 'cours-lumiere';
danger

Opération irréversible : toutes les données de l'organisation seront perdues.

Configuration post-provisioning​

  1. Sites — POST /admin/org/sites (horaires et timezone repris de l'organisation)
  2. Catégories — POST /admin/org/product-categories
  3. Produits — POST /admin/org/products ou import en lot
  4. Utilisateurs N1 — POST /admin/org/users, puis assignation de rôles via POST /admin/org/users/{id}/roles
  5. Points de vente — POST /admin/org/points-of-sale
  6. Notifications — ajuster notification_config via PUT /admin/org/settings
  7. Seuil d'anomalie — PUT /admin/system/organizations/{id} (default_anomaly_threshold_cents)

Voir aussi​