Rappel sur les rôles et les groupes utilisateurs. Présentation des options de gestion des groupes offertes par Voozanoo 4.
Introduction
La gestion des groupes utilisateurs sur un projet Voozanoo 4 n’est pas toujours évidente à appréhender. Cet article a pour but d’éclaircir le fonctionnement actuel des groupes utilisateurs et de présenter une nouvelle fonctionnalité permettant de modifier ce fonctionnement.
Définition des groupes utilisateurs
Rappel sur les rôles
Pour comprendre l’intérêt des groupes utilisateur, il faut en premier lieu comprendre à quoi servent les rôles.
La gestion des privilèges des utilisateurs d’un projet se fait via l’attribution de rôles. Un rôle permet de paramétrer une série de privilèges de façon générique :
- L’accès aux fonctionnalités : Ce paramétrage est disponible dans l’onglet “Fonctionnalités” du formulaire des gestion des rôles. Il permet de sélectionner les actions qu’un utilisateur avec ce rôle aura le droit de mener. D’un point de vue technique, il s’agit des contrôleurs auxquels l’utilisateur a accès.
- L’accès aux données : Ce paramétrage est disponible dans l’onglet “Données” du formulaire des gestion des rôles. Il permet de sélectionner les ressources sur lesquelles ces actions pourront être menées. Deux filtres sont disponibles : le type d’accès aux données (en Lecture, Ecriture et/ou Suppression) et le périmètre d’accès (Tous : je donne l’accès à l’ensemble de ces données, Groupe : je ne donne l’accès qu’aux données appartenant à certains groupes qui seront définis au niveau de chaque utilisateur, Propriétaire : je ne donne l’accès qu’aux données qui appartiennent à l’utilisateur lui-même )
Lors de l’attribution d’un rôle à un utilisateur, un périmètre doit être spécifié en sélectionnant le(s) groupe(s) sur le(s)quel(s) ce rôle va s’appliquer. Ce choix impactera l’accès aux données de l’utilisateur si le périmètre de cet accès est au niveau “Groupe”.
Par exemple, je souhaite que les utilisateurs avec le rôle “Médecin” aient le droit d’ajouter des fiches patients et de les modifier mais uniquement pour les fiches patients de l’hôtipal où ils exercent. Je définis donc le rôle “Médecin” en cochant :
- Les fonctionnalités “Afficher un enregistrement” et “Modifier un enregistrement”
- Les colonnes “Lecture” et “Ecriture” au niveau du “Groupe” pour les données “Patient”
Puis j’attribue le rôle médecin aux utilisateurs concernés sur le groupe représentant leur hôpital.
Afin que le paramétrage de l’accès aux données soit possible, chaque fiche (ou enregistrement) appartient nécessairement à au moins un groupe. La même règle s’applique aux utilisateurs (une fiche utilisateur n’étant, au final, qu’un enregistrement comme les autres). On parle alors du/des groupe(s) d’appartenance1 de l’utilisateur (Group(s) membership en anglais). Lorsque l’on parle des groupes utilisateur, nous avons donc 2 catégories de groupe : le(s) groupe(s) d’appartenance et le(s) groupe(s) sur le(s)quel(s) l’utilisateur a un rôle.
Les groupes d’appartenance
Par défaut, le(s) groupe(s) d’appartenance est/sont défini(s) à la création de l’utilisateur et correspond(ent) au(x) groupe(s) sur le(s)quel(s) le créateur à un/des rôle(s). Cette information est stockée dans la table {pj}_user_data_group de la base de données et correspond à la variable sys_group côté client.
Les combinaisons rôle/groupe
Chaque combinaison rôle/groupe attribuée à un utilisateur est stockée dans la table {pj}_pj_group_link. Ces groupes conditionnent :
- l’accès aux données de l’utilisateur si son rôle a un accès aux données limité au niveau “Groupe”.
- le(s) groupe(s) d’appartenance des enregistrements effectués par l’utilisateur.
Une distinction importante
Le(s) groupe(s) d’appartenance d’un utilisateur ne définisse(nt) en rien ses droits d’accès ou son périmètre d’action. A contrario, le fait qu’un utilisateur ait un rôle sur un groupe n’implique pas nécessairement qu’il appartienne à ce groupe.
La gestion des groupes utilisateurs
Le fontionnement par défaut
Comme expliqué plus haut, par défaut, le(s) groupe(s) d’appartenance d’un utilisateur correspondera/dront au(x) groupe(s) sur le(s)quel(s) l’utilisateur qui est en train de le créer a un/des rôle(s). Ce fonctionnement peut être perturbant pour plusieurs raisons. D’une part, on peut s’attendre à ce que, si un utilisateur a un rôle sur un groupe, il appartiennet automatiquement à ce groupe ; d’autre part, si un utilisateur à un/des rôle(s) sur plusieurs groupes, on ne souhaite pas nécessairement que les utilisateurs qu’il crée appartiennent à tous ces groupes.
Afin d’offrir plus de souplesse et de logique à ce fonctionnement, un paramètre est désormais disponible au niveau du projet et propose 3 modes de gestion des groupes d’appartenance des utilisateurs.
3 modes de gestion
Le mode “Désactivé”
Permet de revenir au fonctionnement par défaut. Il s’agit du paramétrage par défaut des projets.
Exemple :
- Un administrateur appartenant a un rôle lui permettant de créer des utilisateurs dans les groupes “Paris”, “Lyon” et “Marseille”.
- Il créée deux utilisateurs :
- L’utilisateur “A” qui a le droit de consulter les fiches patients de “Paris”
- L’utilisateur “B” qui a le droit de consulter les fiches patients de “Lyon” -> Les utilisateurs “A” et “B” appartiennent aux groupes “Paris”, “Lyon” et aux groupes parents1 de ces deux groupes. Plus concrètement, si on fait un listing ou un export des utilisateurs appartenant au groupe “Paris”, on y retrouvera à la fois les utilisateurs “A” et “B”
Le mode “Automatique”
Si ce mode est activé, à chaque création, modification ou suppression d’un couple rôle/groupe sur une fiche utilisateur, son/ses groupe(s) d’appartenance est/sont automatiquement mis à jour pour correspondre aux(x) groupe(s) sur le(s)quel(s) l’utilisateur à des droits. Le même fonctionnement est appliqué automatiquement lors de l’import d’utilisateurs.
Si l’on reprend l’exemple de la section précédente : -> L’utilisateur “A” appartient automatiquement au groupe “Paris” (et ses groupes parents1) et l’utilisateur “B”, au groupe “Lyon” (et ses groupes parents1). On ne retrouvera donc que l’utilisateur “A” dans un listing des utilisateurs “Paris” et l’utilisateur “B” dans un listing des utilisateurs “Lyon”.
Le mode “Manuel”
Ce mode permet de modifier le(s) groupe(s) d’appartenance individuellement pour chaque utilisateur. S’il est activé :
- un champ de modification du/des groupe(s) d’appartenance apparait dans le formulaire de création/édition des utilisateurs.
- une colonne est ajoutée au listing des utilisateurs afin d’afficher le groupe d’appartenance.
- une colonne “dynamic_group_membership” doit être ajoutée lors de l’import d’utilisateurs afin d’indiquer si l’on souhaite que le(s) groupe(s) d’appartenance(s) correspondent au(x) groupe(s) sur le(s)quel(s) les utilisateurs un/des rôle(s). Pour chaque ligne définissant un utilisateur, colonne peut-être vide (on garde le comportement par défaut) ou prendre les valeurs 1, pour activer la correspondance entre groupe d’appartenance et rôle/groupe, ou 0, pour conserver le fonctionnement par défaut.
En reprenant l’exemple présenté dans la section précédente : -> L’administrateur peut alors choisir à quel groupe doit appartenir chaque utilisateur :
et décider que :
- l’utilisateur “A” appartient à “Paris” (et à ses groupes parents1) et l’utilisateur “B” appartiennent à “Lyon” (et à ses groupes parents1). Pour un listing, on obtiendra alors le même résultat que si on avait été en mode autommatique.
- l’utilisateur “A” appartient à “Paris” (et à ses groupes parents1) et l’utilisateur “B” appartiennent à “Lyon” et, pour un besoin quelconque, à “Marseille” (et à leurs groupes parents1). On verra alors l’utilisateur “B” si on effectue un listing des utilisateurs de “Marseille” ou un listing des utlisateur de “Lyon”.
WARNING : Le cas particulier de sa propre fiche utilisateur
Quelque soit le mode de gestion choisi, son/ses groupe(s) d’appartenance ou encore le(s) groupe(s) sur le(s)quel(s) il a un/des rôle(s), un utilisateur aura toujours accès à ses propres informations utilisateurs.