Groupes, rôles et droits
Groupes, rôles et droits
Groupes, rôles & droits
Principe : les droits vivent dans le groupe
Dans un tenant, les droits d’un utilisateur sont ceux de son groupe. Un utilisateur
appartient à un et un seul groupe (champ groupId de l’utilisateur, obligatoire) et
hérite des rôles qui y sont attachés. Un groupe peut, lui, compter autant
d’utilisateurs que nécessaire — ou un seul, lorsqu’on veut des droits « individuels ».
Le tenant désigne par ailleurs un groupe par défaut (defaultGroupId ; ce groupe
porte alors isDefault: true), auquel un utilisateur est rattaché automatiquement lors de
certains provisionnements (Azure, Google, Keycloak, etc.).
Un groupe définit :
- des rôles (
userRoles) — ce que ses membres ont le droit de faire (section Les rôles (userRoles)) ; - des autorisations inter-groupes — agir sur les utilisateurs et les parapheurs d’autres groupes (section Autorisations inter-groupes) ;
- un cadrage de l’usage des modèles, des dispositions de métadonnées et de la visibilité des destinataires (section Cadrage de l’usage) ;
- une politique d’invitations groupées (section Invitations groupées (groupedInvitations)).
À la mise en place de votre tenant, l’éventail des groupes et des droits disponibles est défini par Goodflag. Vous administrez ensuite librement vos groupes dans ce cadre.
L’intérêt principal des groupes est d’isoler des groupes d’utilisateurs les uns par rapport aux autres. Ainsi par exemple il peut être intéressant pour les utilisateurs clients de l’entreprise de faire partie d’un groupe “Clients” et ainsi de disposer de la possibilité de se connecter au portail avec leur propre compte leur permettant de visualiser leurs propres parapheurs uniquement. Dans un autre cas, il peut être souhaitable pour les membres d’un groupe d’utilisateurs “RH” appartenant au département des ressources humaines de visualiser tous les parapheurs de tous les membres du groupe.
Créer & configurer un groupe
La réponse renvoie le groupe créé (id préfixé grp_, isDefault, dates, ETag…).
Les rôles (userRoles)
Les rôles se répartissent en trois familles. Le champ userRoles attend la liste des
identifiants ci-dessous.
Rôles basiques
Rôles d’administration
Rôles de développement
Autorisations inter-groupes
Par défaut, un rôle porte sur les objets propres à l’utilisateur ou à son groupe. Pour déléguer à un groupe le droit d’agir sur les utilisateurs ou les parapheurs d’autres groupes, on renseigne huit listes d’identifiants de groupes :
Chaque liste contient les identifiants des groupes dont les membres reçoivent
l’autorisation. L’alias self désigne le groupe courant. Exemple : un groupe
« Back-office » qui gère les utilisateurs et parapheurs des groupes métier.
Cadrage de l’usage
- Modèles —
templateSelectionModegouverne l’emploi des modèles par les créateurs de parapheurs du groupe :
- Dispositions de métadonnées —
layoutSelectionModefonctionne à l’identique, avecallowedLayouts. - Destinataires —
hideWorkflowRecipientsmasque aux membres les autres destinataires d’un parapheur.
Invitations groupées (groupedInvitations)
Permet de regrouper les notifications envoyées aux membres du groupe plutôt que de les envoyer une par une :
mode— activation du regroupement ;activeDays— jours de la semaine d’envoi ;sendingSlots— créneaux d’envoi, chacun avectime(formatHH:mm) etzone(ex.Europe/Paris).
Cycle de vie d’un groupe
- Consulter —
GET /api/groups/{id}. - Modifier —
PATCH /api/groups/{id}(concurrence optimisteIf-Match, fondation Structure > Concurrence : l’en-tête conditionnelIf-Match). - Supprimer —
DELETE /api/groups/{id}. - Lister / rechercher —
GET /api/groups(filtres et pagination, fondation Structure > Recherche & pagination).

