Rôles et permissions

Les droits ne sont pas attachés aux personnes. Ils sont attachés à des rôles, chaque rôle porte une liste de permissions, et un membre détient un rôle dans l’organisation. Ses droits sont ceux de son rôle, ni plus, ni moins.

Tout se règle dans l’onglet Rôles & Permissions de l’écran Administration.

Permissions requises

admin.manage — pour lire comme pour écrire. La cartographie des droits d’une organisation n’est pas ouverte à ses membres ordinaires : la liste des rôles, leurs permissions et le catalogue des permissions existantes exigent tous cette permission.

Les rôles livrés avec l’organisation

À sa création, une organisation reçoit cinq rôles. Ils ne sont pas à vous imposer : ils sont là pour qu’une collectivité toute neuve puisse rattacher son premier agent sans avoir d’abord à inventer un modèle de droits.

En détail :

• acheteur porte settings.read, procurement.read, procurement.write et analytics.read ;
• lecteur porte crm.read, inventory.read, billing.read, hr.read, accounting.read, settings.read, procurement.read et analytics.read ;
• commercial porte crm.read, crm.write, billing.read, billing.write et analytics.read.

Ces cinq rôles vous appartiennent. Vous pouvez ajuster leurs permissions, les renommer, en créer d’autres, en supprimer. C’est délibéré : une collectivité n’a pas les mêmes découpages qu’une autre, et un catalogue immuable obligerait chacune à repartir de zéro.

Le catalogue des permissions

Seize permissions, et c’est la liste complète. Une permission porte un nom de la forme module.action, une description, et le couple module / action qui la situe.

La granularité des achats publics est grossière, et il faut le savoir

C’est le point le plus important de cette page pour qui distribue des rôles.

Tout le cœur du produit — marchés, mandats, budgets, cartographie, fournisseurs, accords-cadres, recherche BPU, estimations, alertes, procédures, services, performance, géo-dépense, nomenclature, veille réglementaire — tourne sur deux permissions : procurement.read et procurement.write.

Il n’existe pas de droit par écran. Qui peut écrire un mandat peut écrire un marché. Qui peut modifier la nomenclature peut modifier un fournisseur. Qui peut consulter les budgets peut consulter la cartographie.

Les permissions dont le module n’est pas au menu

crm.*, inventory.*, billing.*, hr.* et accounting.* figurent dans le catalogue ci-dessus, et apparaissent donc dans l’écran de composition des rôles. Les entrées correspondantes ne figurent pas dans le menu de l’application.

Nous les listons parce que la liste doit être fidèle, pas parce qu’elles désignent des fonctionnalités à votre disposition. Ne construisez pas un modèle de droits qui s’appuie dessus, et interrogez le support avant de compter sur l’une d’elles.

Composer un rôle

La barre de rôles, en haut de l’onglet, affiche un bouton par rôle — un cadenas signale un rôle système — et un bouton Nouveau rôle. Sélectionner un rôle ouvre sa fiche.

La fiche porte le nom du rôle, sa description, et jusqu’à trois actions :

Dupliquer est disponible sur tous les rôles ; Éditer et Supprimer n’apparaissent que sur les rôles non système.

La matrice des permissions

Un tableau à trois colonnes — Module, Lire, Écrire — avec un interrupteur par case. Les huit lignes sont :

Deux lignes se comportent à part. Analytics n’a pas de permission d’écriture. Administration porte un interrupteur unique, dans la colonne Lire, et la colonne Écrire affiche un tiret : admin.manage ne se décline pas en lecture et écriture.

Les interrupteurs se répondent, pour éviter des combinaisons qui n’ont pas de sens : activer Écrire active Lire ; désactiver Lire désactive Écrire. Chaque bascule est enregistrée immédiatement, et un message confirme (« Permissions mises à jour »).

Les rôles système

Un rôle système porte un cadenas dans la barre de rôles et une étiquette SYSTÈME dans sa fiche. Sa matrice de permissions est grisée, et un bandeau l’explique : « Les rôles système ne peuvent pas être modifiés directement. Utilisez Dupliquer pour créer une copie personnalisable. »

Ce refus n’est pas une précaution de principe. Un rôle système n’appartient pas à une seule organisation : c’est un rôle de catalogue, attribuable par plusieurs. En modifier les permissions ou le périmètre les changerait pour toutes celles qui l’attribuent, sans que personne ne le voie passer. D’où la règle : on duplique, et on travaille sur la copie, qui appartient à l’organisation.

L’API refuse ces écritures avec un code 403 et le message « impossible de modifier un rôle système ». Les cinq rôles livrés à la création d’une organisation, eux, ne sont pas système : ils vous appartiennent et sont modifiables.

Le périmètre de données

Au-dessus de la matrice, un bloc Périmètre de données propose deux options exclusives :

Les permissions disent ce que le rôle peut faire ; le périmètre dit sur quoi. Les deux se combinent, et le périmètre n’accorde jamais rien — il ne peut que restreindre. Le défaut est Tous les services : restreindre est un acte explicite.

Quand un rôle est réglé sur Ses services uniquement, l’écran rappelle où se fait l’autre moitié du travail : « Le rattachement aux services se fait par membre, dans l’onglet Utilisateurs. Un membre restreint sans service rattaché ne voit que les marchés sans service. » Voir Membres.

Sur un rôle système, l’écran avertit que le réglage peut rester sans effet et renvoie vers Dupliquer.

Les deux refus qu’on ne comprend pas sans explication

Vos rôles vous appartenant, rien n’empêcherait de supprimer celui qui porte admin.manage, ou de lui retirer cette permission — après quoi plus personne ne pourrait administrer l’organisation, pas même pour réparer, puisque recréer un rôle exige précisément cette permission. Deux garde-fous s’y opposent, et ils ne disent pas la même chose.

Le dernier rôle qui porte l’administration

Si le rôle visé est le seul de l’organisation à porter admin.manage, sa suppression est refusée avec :

ce rôle est la dernière voie d’administration de l’organisation : créez-en un autre portant « admin.manage » avant de retirer celui-ci

La marche à suivre est dans le message : créez d’abord un autre rôle portant l’administration, puis revenez supprimer celui-ci.

Le dernier porteur de l’administration

Compter les rôles ne suffit pas : un rôle que personne ne détient ne sauve personne. Si l’opération ne laisserait plus aucune personne en mesure d’administrer, le refus est :

ce rôle est le seul que détienne un administrateur : attribuez d’abord à quelqu’un un autre rôle portant « admin.manage », sinon plus personne ne pourra administrer l’organisation

Ici, créer un rôle ne débloque rien : il faut l’attribuer à quelqu’un. C’est la différence entre les deux messages, et elle est la raison d’être du second.

Dans les deux cas, la réponse est un code 409 et non 403 : la demande est légitime et vous en avez le droit, c’est l’état de l’organisation qui l’interdit. Un 403 enverrait chercher du côté des permissions, au mauvais endroit.

Un rôle qui ne porte pas admin.manage n’est jamais concerné par ces refus.

Limites connues

• settings.read et settings.write ne se règlent pas depuis la matrice.
• Pas de droit par écran sur le périmètre achats (voir ci-dessus).
• Un rôle système ne se modifie pas, y compris son périmètre de données : il faut le dupliquer.
• L’accès à l’écran Administration dépend du nom du rôle actif. L’application y conduit les rôles nommés owner et admin ; un rôle personnalisé portant admin.manage peut être renvoyé vers le tableau de bord alors que l’API, elle, accepterait ses appels. Si vous créez un rôle d’administration sous un autre nom, vérifiez qu’il ouvre bien l’écran avant de l’attribuer.
• L’interface n’attribue qu’un rôle à la fois, et ne permet pas de composer un membre à partir de plusieurs rôles. Mais un changement de rôle ne se comporte pas forcément comme un remplacement : voir l’avertissement sur Membres : un changement de rôle remplace le précédent, et prend effet sans attendre une reconnexion.