Documentation

Appearance

Modèle de droits — Rapport (console interne) ​

Périmètre : Rapport ne crée pas d'utilisateurs (ils viennent du SSO / console centrale). Les Administrateurs de l'entreprise (dans Rapport) attribuent des droits fins à chaque utilisateur, directement ou via des groupes : par établissement, par domaine (Finance/RH/Métier), par dossier (Tableaux de bord / Vues / Saisie / Écarts / KPI / Pivot / Modélisation). Indépendant du SSO : tout repose sur une abstraction « utilisateur courant » que le SSO remplira.

1. Entités (côté Rapport) ​

  • User (miroir) : id (= userId SSO), entrepriseId, email, name, role (admin | modeleur | lecteur), groupIds: string[], lastSeenAt. Créé/mis à jour à la connexion SSO. Jamais créé manuellement.
  • Group (nouveau) : id, entrepriseId, name, permission: Permission (même forme que ci-dessous). Créé/géré dans la Console des droits. Les permissions d'un groupe s'appliquent à tous ses membres.
  • Permission (portée par un User individuellement, et par chaque Group) :
    • establishments: string[] — établissements visibles (vide = tous ceux de l'entreprise)
    • domains: ("finance"|"rh"|"metiers"|…)[] — domaines visibles (vide = tous ceux de l'abonnement)
    • folders: { dashboards, views, saisie, ecarts, kpi, pivot, modelisation } où Access = "none" | "read" | "edit"
    • (option future) dashboardIds[] / viewIds[] pour restreindre à des objets précis
  • (Entreprise / Établissement / Module / Licence : possédés par la console centrale ; lus via SSO/API, pas redéfinis ici.)

Rôles comme préréglages, pas comme contrainte ​

role reste un préréglage de départ (cf. section 1bis), appliqué à la création ou à l'affectation à un groupe. La Permission effective (individuelle ou de groupe) reste éditable finement au cas par cas ensuite — le rôle ne verrouille pas ce qui est possible, il accélère la configuration initiale.

Libellé affiché vs identifiant technique : l'identifiant technique (admin | modeleur | lecteur) reste en minuscule dans le code, mais le libellé affiché à l'écran (Console des droits, sélecteur de rôle) doit être Administrateur / Modeleur / Lecteur — cohérent avec ce qui existe déjà dans l'écran Console des droits actuel ("Administrateur" y figure déjà). Ne pas afficher "Admin" tronqué à l'écran.

1bis. Préréglages de rôle ​

Rôledashboardsviewssaisieecartskpipivotmodelisation
lecteurreadreadnonenonenonereadnone
modeleurreadreadediteditediteditnone
adminediteditediteditediteditedit

Ces préréglages s'appliquent aussi bien à un User qu'à un Group — un groupe peut être créé directement à partir d'un rôle ("Groupe Modeleurs EHPAD"), puis ajusté finement si besoin (ex. retirer kpi pour ce groupe précis).

2. Résolution des permissions effectives (User + Groupes) ​

Un utilisateur peut appartenir à plusieurs groupes, en plus de sa Permission individuelle propre. La permission effective se calcule par fusion la plus permissive, ressource par ressource :

effectivePermission(user) = merge(
  user.permission,               // permission individuelle propre
  ...user.groups.map(g => g.permission)  // permissions de chaque groupe d'appartenance
)

merge sur `folders` : pour chaque ressource, Access effectif = le plus permissif parmi toutes les sources
                       (none < read < edit)
merge sur `establishments` / `domains` : union des ensembles
                       (vide sur une source = "tous" → l'emporte sur les autres, résultat = tous)

Principe retenu : additif, jamais restrictif. Un groupe ou une permission individuelle ne peut qu'élargir l'accès d'un utilisateur, jamais le retirer par rapport à une autre source. Si ce comportement doit un jour être affiné (ex. un groupe qui retire un droit accordé individuellement), ce sera un changement de modèle explicite, pas une extension silencieuse de celui-ci — à éviter tant qu'un besoin réel ne l'impose pas, pour rester lisible dans la matrice de droits.

Abstraction « utilisateur courant », mise à jour ​

CurrentUser = {
  id, entrepriseId, role: "admin" | "modeleur" | "lecteur",
  groupIds: string[],
  establishmentsAllowed: string[],   // résultat de la fusion, vide = tous
  domainsAllowed: string[],          // résultat de la fusion, vide = tous
  folders: { dashboards, views, saisie, ecarts, kpi, pivot, modelisation }, // résultat de la fusion
}
  • Aujourd'hui : remplace le faux toggle admin (App.tsx, TODO: rôle réel) par un CurrentUserProvider (mock configurable), incluant la logique de fusion groupe/individuel.
  • Demain : alimenté par le jeton SSO (identité + appartenance aux groupes) + la Permission lue en base.

3. Console de droits (écran Administrateur Rapport) ​

  • Onglet Utilisateurs & Groupes :
    • Liste des utilisateurs de l'entreprise (lus du SSO — non créables, non supprimables ici). Par utilisateur : rôle (préréglage), établissements, appartenance aux groupes, Permission individuelle éditable en complément.
    • Liste des groupes : création (+ Groupe), nommage, rôle de départ (préréglage), Permission éditable, liste des membres.
  • Onglet Matrice — qui voit quoi :
    • Colonnes = utilisateurs et groupes (déjà prévu dans l'écran existant).
    • Lignes = ressources, à compléter avec les nouvelles : Restitution (vues), Rapports, Tableaux de bord, Saisie/Projection, Écarts, KPI, Vue pivot, Modélisation, Administration.
    • Clic cellule = accorder/retirer, comme aujourd'hui — mais afficher la permission effective (résultat de la fusion) distinctement de la permission explicite propre à cette colonne, pour que l'admin comprenne pourquoi un utilisateur a accès à quelque chose qu'il n'a pas coché lui-même (hérité d'un groupe).

4. Application des droits (enforcement) ​

  • Établissement : restreindre l'axe établissement aux establishmentsAllowed (résultat de fusion) → réutilise le mécanisme de restriction de filtre déjà en place.
  • Domaine : masquer sources / dimensions / vues / dashboards hors domainsAllowed (résultat de fusion).
  • Dossier : masquer/limiter les sections selon folders (résultat de fusion), y compris les nouvelles ressources (Écarts, KPI, Pivot, Modélisation).
  • Backend : à terme, filtrer aussi les endpoints selon la permission effective (individuelle + groupes), pas seulement la permission individuelle.

5. Étapes proposées ​

  1. CurrentUserProvider + logique de fusion (individuel + groupes) + remplacement du faux toggle admin — frontend, sans SSO.
  2. Modèle User + Group + Permission (Prisma) + endpoints CRUD (Administrateur uniquement), y compris affectation d'un user à un ou plusieurs groupes.
  3. Console de droits : onglet Groupes (création, permission, membres) + mise à jour de la Matrice pour distinguer permission propre vs effective.
  4. Extension de folders aux nouvelles ressources (écarts, kpi, pivot, modelisation) et application des préréglages de rôle (section 1bis).
  5. Enforcement frontend (établissement / domaine / dossier), sur la permission effective fusionnée.
  6. Branchement SSO (selon sso-contract.md) → utilisateur courant et appartenance aux groupes viennent du jeton.
  7. Enforcement backend (sécurité réelle des endpoints), sur la permission effective fusionnée.

Ordre choisi pour avancer sans bloquer sur le SSO : 1→5 d'abord (visible, testable), puis 6→7 avec le CTO.