Permissions & Rôles

Canopy utilise un modèle de permissions à trois couches qui combine un contrôle d'accès basé sur les rôles à l'échelle de l'application avec des rôles de parties prenantes spécifiques à chaque fiche. Cette page explique la conception, quand utiliser chaque couche et comment les couches se combinent pour former des permissions effectives.

Pourquoi trois couches ?

L'architecture d'entreprise est par nature transversale. Une fiche donnée – par exemple, une Application – peut être :

• En lecture seule pour la plupart des utilisateurs (les visiteurs voient l'inventaire mais ne peuvent pas le modifier)
• Modifiable par l'équipe EA générale (les membres peuvent mettre à jour n'importe quelle fiche)
• Gérée par une personne précise responsable de cette application (le Technical Application Owner peut modifier et approuver le statut, même s'il n'a pas de droits de modification à l'échelle de l'organisation)
• Entièrement contrôlée par les administrateurs (qui peuvent tout faire)

Un système de rôles plat gère les trois premiers cas mais échoue sur le quatrième : soit vous accordez à quelqu'un des droits de modification à l'échelle de l'organisation (trop large), soit rien (trop restrictif). La couche des parties prenantes résout ce problème en accordant des permissions par fiche à des personnes nommées.

Couche 1 — Rôles applicatifs

Les rôles applicatifs sont attribués aux utilisateurs et s'appliquent sur l'ensemble de la plateforme. Ils sont définis et gérés dans Admin → Utilisateurs & Rôles.

Chaque rôle porte un ensemble de permissions JSON. Les rôles intégrés sont :

Rôle	Clé	Portée
Admin	admin	Joker {"*": true} – sans restriction
BPM Admin	bpm_admin	BPM complet + inventaire complet, sans admin.*
Member	member	Inventaire complet + modification BPM, sans admin.*
Viewer	viewer	Lecture seule dans tous les domaines

Des rôles personnalisés peuvent être créés avec n'importe quelle combinaison des clés de permission disponibles, regroupées en domaines tels que inventory.*, reports.*, bpm.*, ppm.*, grc.*, todos.*, admin.*.

Utilisez les rôles applicatifs lorsque vous devez contrôler ce qu'une catégorie d'utilisateurs peut faire sur toute la plateforme.

Couche 2 — Rôles de parties prenantes

Les rôles de parties prenantes sont attribués aux utilisateurs sur des fiches précises. Chaque type de fiche définit son propre ensemble de définitions de rôles de parties prenantes (par ex. les fiches Application ont « Technical Application Owner », « Business Application Owner », « Data Steward »). Ceux-ci sont configurés dans Admin → Métamodèle → [type] → Rôles des parties prenantes.

Chaque définition de rôle de partie prenante porte un ensemble de permissions au niveau de la fiche – des choses comme card.edit, card.approve, card.manage_relations. Lorsqu'un utilisateur est ajouté comme partie prenante sur une fiche, il gagne ces permissions uniquement sur cette fiche.

Utilisez les rôles de parties prenantes lorsque la propriété ou la responsabilité est spécifique à une fiche : le propriétaire d'une application particulière doit pouvoir la gérer sans obtenir des droits de modification sur les 500 autres applications.

Couche 3 — Permissions effectives

Lorsqu'un utilisateur tente une action sur une fiche, le système calcule ses permissions effectives en combinant :

1. Ses permissions de rôle applicatif (mappées des clés de niveau plateforme aux clés de niveau fiche)
2. Toutes les permissions de rôle de partie prenante qu'il détient sur cette fiche précise

Le résultat est l'union des deux ensembles. Un utilisateur qui est un Viewer (à l'échelle de la plateforme) mais un Technical Application Owner sur une fiche peut modifier cette fiche, car le rôle de partie prenante accorde card.edit même si le rôle Viewer ne le fait pas.

Les permissions effectives de l'utilisateur actuel sur une fiche donnée sont exposées à GET /cards/{id}/effective-permissions et pilotent tous les contrôles de modification, d'approbation et de suppression dans l'interface.

Le joker administrateur

Le rôle Admin utilise {"*": true} comme ensemble de permissions. Cela est évalué comme « tout autoriser » – y compris les permissions qui n'existaient pas lors de la création du rôle. Cela signifie que les nouveaux modules et les nouvelles clés de permission sont automatiquement disponibles pour les administrateurs sans aucune mise à jour de rôle.

Aucun autre rôle intégré n'utilise le joker. Lors de la création de rôles personnalisés, utilisez des clés de permission explicites plutôt que des jokers – cela rend la portée du rôle auditable et évite une attribution accidentelle excessive.

Structure des clés de permission

Toutes les clés de permission suivent un modèle domaine.action :

• inventory.view – lire les fiches
• inventory.edit – mettre à jour les fiches
• inventory.create – créer des fiches
• admin.metamodel – gérer les types de fiches et les types de relations
• admin.impersonate – agir temporairement comme un rôle différent (voir Usurpation de rôle)
• bpm.approve – approuver des versions de flux de processus BPMN
• todos.view / todos.create / todos.manage – accéder aux tâches et les gérer
• risks.manage – créer et mettre à jour les entrées du registre des risques

La liste complète des clés valides se trouve dans backend/app/core/permissions.py, qui est la source unique de vérité. Les nouvelles clés de permission doivent y être ajoutées avant de pouvoir être accordées à un rôle.

Schémas courants

Restreindre un module à une équipe : Créez un rôle personnalisé avec uniquement les permissions ppm.* et inventory.view. Attribuez-le à l'équipe de portefeuille de projets. Elle peut travailler dans PPM mais ne peut pas modifier l'inventaire principal.

Accorder des droits d'approbation sans droits de modification : Donnez à une partie prenante métier le rôle de partie prenante « Business Application Owner » sur des fiches Application précises. Configurez ce rôle pour inclure card.approval_status mais pas card.edit. Elle peut approuver les fiches que l'équipe EA a renseignées, mais ne peut pas modifier les données.

Accès d'urgence pour un administrateur : Le joker administrateur signifie que toute permission future – y compris les permissions ajoutées par des extensions ou des versions futures – est automatiquement accordée. Utilisez le rôle Admin uniquement pour les utilisateurs qui ont réellement besoin d'un accès illimité.

Tester avec un rôle spécifique : Les utilisateurs avec admin.impersonate peuvent passer dans n'importe quel rôle non-administrateur depuis le menu utilisateur (Voir en tant que rôle…) pour vérifier exactement ce que ce rôle peut voir et faire – sans créer de compte de test séparé. La session d'usurpation est uniquement basée sur JWT et ne laisse aucune trace sur le compte sous-jacent. Voir Usurpation de rôle pour le workflow complet.

Voir aussi

• Utilisateurs & Rôles – créer et modifier des rôles applicatifs
• Administration du métamodèle – configurer les rôles de parties prenantes par type de fiche
• Détail de la fiche : onglet Parties prenantes – attribuer des parties prenantes à une fiche