groupe-meditation/docs/MULTI_TENANCY.md

Isolation multi-groupe

L'application est servie sous une URL commune, mais les donnees d'un groupe doivent rester isolees de celles des autres groupes. Le contexte actif est toujours le groupe_id du membre authentifie, transporte dans le jeton de session et verifie au chargement du membre.

Regles d'isolation

• Une requete authentifiee ne doit lire ou modifier que les donnees du groupe du membre courant.
• Les postes, affectations, candidatures, rotations, reunions, assemblees, propositions, transactions, reserves et journaux sont des donnees de groupe.
• Les permissions de modules sont derivees des postes du groupe courant seulement.
• Le calendrier affiche uniquement les serviteurs du groupe courant. Il ne fait pas de lecture district ou multi-groupe.
• Les liens invites donnent acces seulement a l'assemblee ciblee par l'invitation et a ses donnees publiques.
• Les tables sans groupe_id direct doivent etre bornees par leur parent : par exemple une presence est bornee par sa reunion, un PV par sa reunion, une permission de module par son poste.

Points de vigilance

• Une route qui accepte un identifiant fourni par le client doit verifier que l'objet appartient au groupe courant avant de l'utiliser.
• Une jointure de permissions doit filtrer a la fois l'affectation et le poste sur le groupe courant.
• Une initialisation ou remise a zero par Sysadmin est une operation d'instance. Elle ne doit pas etre exposee comme operation courante en production multi-groupe.
• Toute nouvelle table metier doit recevoir un groupe_id, sauf si son rattachement a une table parent isolee est strict et documente.

Etat actuel

Les postes sont maintenant scopes par groupe_id, ce qui evite qu'un groupe modifie les definitions de postes ou les permissions d'un autre groupe. Les routes de calendrier, de postes, d'assemblees et de rotations filtrent les donnees par groupe courant.