Je souhaiterais savoir s’il existe une méthode simple et rapide dans Simplicité pour rendre tous les champs d’un objet non modifiables en fonction d’un profil utilisateur donné, via une contrainte globale, sans devoir paramétrer un impact champ par champ (utile si objet avec beaucoup d’attributs).
Version actuelle du socle Simplicite : 5.1.66
Contexte :
Objet concerné : NamJeune
Nombre important de champs (environ une centaine)
Objectif : Interdire la modification des champs de l’objet aux utilisateurs ayant le rôle NAM_DSIN, tout en leur laissant l’accès en lecture.
Solution testée (non concluante) :
J’ai créé une contrainte avec effet frontend, de type expression, portée sur l’objetNamJeune :
Lors de mes tests, les utilisateurs disposant du rôle NAM_DSIN peuvent toujours modifier les valeurs des champs et enregistrer les modifications. Cela ne semble donc pas suffisant pour bloquer les actions de mise à jour sur l’objet.
Attentes :
Je cherche une solution plus simple que de définir un impact pour chacun des attributs manuellement (ce qui serait très lourd à maintenir), par exemple :
Une contrainte de type expression sur l’objet qui empêche toutes modifications en une seule fois ?
Un mécanisme natif ou une bonne pratique recommandée pour ce type de besoin ?
De manière générale, la bonne pratique est d’associer au groupe uniquement une fonction en lecture seule et non CRUD.
Cependant, si le profil utilisateur inclut un autre groupe qui a également les droits de modification, l’objet restera modifiable.
Nous recommandons de concevoir les groupes de sorte à ajouter des droits au profil plutôt que d’essayer d’en retirer.
Si vous ne pouvez pas réduire les droits au niveau du groupe, il est également possible de le faire par code dans l’objet :
Si la modification doit être impossible, quel que soit le contexte (liste, panel, formulaire, etc.) :
Vous pouvez surcharger le hook postLoad de l’objet et utiliser la fonction changeAccess pour modifier les droits :
@Override
public void postLoad() {
Grant g = getGrant();
if(g.hasResponsibility("NAM_DSIN")){
g.changeAccess("NamJeune",false,true,false,false);//String obj, boolean create, boolean read, boolean update, boolean delete
}
}
Si vous souhaitez une gestion plus fine des accès :
Vous pouvez surcharger le hook isUpdateEnable de l’objet en fonction du contexte.
L’une de ces solutions correspond-elle à votre besoin ?
Cordialement,
Candice.
Effectivement, la configuration des fonctions pour chaque groupe avait bien été réalisée, avec une fonction en lecture seule attribuée au groupe NAM_DSIN. Cependant, l’utilisateur concerné est membre de plusieurs groupes, dont certains disposent de droits en création/modification (CRUD), ce qui semble primer sur la restriction prévue pour NAM_DSIN.
Afin de répondre au besoin, nous avons opté pour la solution suivante que vous nous avez suggéré, consistant à surcharger le hook postLoad() de l’objet NamJeune pour forcer dynamiquement les droits d’accès de l’utilisateur :
@Override
public void postLoad() {
Grant g = getGrant();
if (g.hasResponsibility("NAM_DSIN")) {
g.changeAccess("NamJeune", false, true, false, false); // (create, read, update, delete)
}
}
Cette approche fonctionne bien dans notre cas.
Cela étant, nous nous permettons de suggérer, pour de futures évolutions du socle Simplicité, l’ajout d’un mécanisme de priorisation des groupes ou d’une stratégie d’arbitrage plus fine en cas de multi-appartenance. Cela permettrait de mieux gérer les droits lorsqu’un utilisateur est rattaché à plusieurs groupes ayant des fonctions différentes (lecture seule vs. CRUD par exemple).
Merci pour votre retour, la priorisation des droits/groupes serait un degré de paramétrage intéressant.
La conception inclusive des droits (par union des droits habilités via ses responsabilités) n’a jamais posé de problème quand on modélise correctement ses profils applicatifs et en factorisant les fonctions communes dans un logique ensembliste ou hiérarchique. Ce qui n’est déjà pas simple quand il y a beaucoup de profils.
Dire que qu’une personne “a et n’a pas” des droits signifie qu’elle a en fait 2 profils, et donc dans Simplicité, il y a la possibilité de créer 2 scopes distincts = elle se connecte en tant que X ou Y mais pas les 2 en même temps.
Bref à mon sens ce sera source de confusion, ou tout du moins amènera une combinatoire rendant l’analyse et les calculs très compliqués, voir impossible de déterminer son vrai profil métier, incohérence de paramétrage ou d’affichage, etc.
Par contre dans un contexte low-code, comme l’a indiqué Candice, il y a suffisamment de possibilité de surcharge pour gérer les cas particuliers comme le votre pour changer les droits dynamiquement en fonction d’un contexte : données, profils, instance d’objet…
