Console Admin Docs

Appearance

Enterprise Domain ​

Definition ​

Une enterprise represente un tenant principal de la console d'administration.

Le type utile pour la console est enterprise. Le type personal existe dans le modele de donnees mais ne doit pas etre melange a la liste des entreprises administrables.

Champs observes ​

Champs frontend et backend actuellement relies au domaine:

  • id
  • name
  • type
  • logo_id
  • FrontVersion
  • maxOrganisations
  • maxUsers
  • environnement
  • created_at
  • updated_at

References:

Regles metier ​

Visibilite ​

  • un super-admin peut voir toutes les entreprises de type enterprise
  • un administrateur ne peut voir que l'entreprise referencee par profile.enterprise_id
  • un utilisateur ne peut pas appeler l'API de liste des entreprises

Important:

  • une entreprise de type personal ne doit jamais apparaitre dans la liste des entreprises
  • ces entreprises sont des faux tenants techniques utilises pour la gestion des comptes personnels
  • si profile.enterprise_id pointe sur une entreprise personal, la liste retournee pour un administrateur doit etre vide

Implementation actuelle:

Tri et filtrage ​

  • la liste doit etre triee par name
  • la liste doit exclure les enregistrements dont type != 'enterprise'
  • en particulier, les enregistrements type = 'personal' sont exclus par defaut

Contexte d'entreprise courant ​

Le frontend maintient un contexte d'entreprise courant.

  • pour un super-admin, ce contexte peut etre change dynamiquement
  • pour un administrateur, l'entreprise de reference provient de profile.enterprise_id

Reference:

Selection par un super-admin ​

Le super-admin peut changer l'entreprise courante en mettant a jour son profile.enterprise_id.

Impact:

  • la selection d'entreprise n'est pas seulement un etat frontend
  • elle est persistee dans Supabase sur profiles

Flux applicatifs ​

Lister les entreprises ​

Flux actuel:

  1. le frontend recupere le token de session Supabase
  2. le frontend appelle GET /enterprises sur le backend
  3. le backend verifie le token
  4. le backend charge profile et role
  5. le backend retourne uniquement les entreprises de type enterprise visibles selon le role

Reference frontend:

Reference backend:

Charger une entreprise par identifiant ​

Etat actuel:

  • le frontend appelle encore Supabase directement via fetchById()
  • ce flux n'est pas encore migre vers back

Impact:

  • il est normal d'observer encore des appels rest/v1/enterprises?id=eq.<id>

Decisions de conception ​

Pourquoi le backend filtre explicitement ​

La regle de visibilite est appliquee explicitement dans le service backend, meme si une partie des droits pourrait aussi etre exprimee via RLS.

Objectifs:

  • rendre la regle lisible dans le code applicatif
  • permettre des tests unitaires et d'integration precis
  • eviter de faire reposer toute la comprehension metier sur des policies SQL

Pourquoi garder une migration progressive ​

Le domaine enterprises est migre pas a pas pour reduire le risque:

  • d'abord la lecture de liste
  • ensuite la lecture par identifiant
  • ensuite les mutations

Cette approche permet de verifier chaque flux en condition reelle avant de migrer le suivant.

Risques connus ​

  • certaines operations enterprise restent directes depuis le frontend vers Supabase
  • le contexte d'entreprise courant cote frontend depend encore de fetchById() en direct
  • il existe une dependance forte a profiles.enterprise_id pour le comportement des admins

Checklist de modification ​

Si une evolution touche le domaine enterprises, verifier:

  • le role super-admin garde-t-il une vision globale ?
  • le role administrateur reste-t-il borne a son enterprise_id ?
  • les enregistrements de type personal restent-ils exclus ?
  • le tri par name est-il preserve ?
  • les tests unitaires et d'integration ont-ils ete adaptes ?