Project

General

Profile

Development #56638

Supprimer la gestion des parents d'un rôle

Added by Paul Marillonnet about 1 month ago. Updated 9 days ago.

Status:
Solution déployée
Priority:
Normal
Category:
-
Target version:
-
Start date:
03 Sep 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Dans #56626 on constate que ne gérer que les fils d'un rôle serait suffisant.


Files

Associated revisions

Revision 5ad1949b (diff)
Added by Paul Marillonnet 17 days ago

manager: provide a human-friendly rbac inheritance terminology (#56638)

History

#2

Updated by Benjamin Dauvergne about 1 month ago

  • Description updated (diff)
  • Subject changed from depuis un rôle ne permettre le pilotage que dans un sens de l’héritage to Supprimer la gestion des parents d'un rôle
#3

Updated by Benjamin Dauvergne about 1 month ago

  • Description updated (diff)
#4

Updated by Stéphane Laget about 1 month ago

Perso, je trouve très pratique de pouvoir gérer les héritages dans les deux sens.
Je ne vois pas l'intérêt de mettre en place cette régression.
C'est très pratique notamment pour gérer le rôle agent.

#5

Updated by Pierre Cros about 1 month ago

Ça sert à rien d'appeler ça régression : less is more. C'est parce que ça entraîne des confusions qu'on parle de simplifier.

Tu viens avec un cas d'usage intéressant le rôle agent pour lequel j'imagine que tu ajoutes dans la partie "hérite des membres de" tous les rôles de la plate-forme (pas forcément plus simple pour moi que d'ajouter le rôle agent dans la partie "hérite des permissions de" sur le rôle que tu es en train de créer, mais je comprends).

Je pense que la solution pour ça serait plutôt un héritage par défaut : on crée un rôle, il hérite par défaut du rôle agent - on désactive ça dans le rôle en question si on le souhaite.

#6

Updated by Stéphane Laget about 1 month ago

Oui un héritage par défaut serait bien pratique, à condition de penser à l'enlever pour les rôles usager, mais qui sont bien plus rares.
(ça veut dire aussi que dans l'api de création de rôles avoir un paramètre pour désactiver cet héritage si nécessaire)

On pourrait aussi laisser "Contient les membres des rôles" dans la partie paramètres avancés comme aujourd'hui, et ne garder la nouvelle interface que pour les rôles enfants (... enfin les rôles qui devraient s'appeler enfants).

#7

Updated by Pierre Cros about 1 month ago

Stéphane Laget a écrit :

Oui un héritage par défaut serait bien pratique, à condition de penser à l'enlever pour les rôles usager, mais qui sont bien plus rares.
(ça veut dire aussi que dans l'api de création de rôles avoir un paramètre pour désactiver cet héritage si nécessaire)

Yep (ou alors ne pas avoir cet héritage automatique via l'API, je ne sais pas, à discuter).

On pourrait aussi laisser "Contient les membres des rôles" dans la partie paramètres avancés comme aujourd'hui, et ne garder la nouvelle interface que pour les rôles enfants (... enfin les rôles qui devraient s'appeler enfants).

Vraiment c'est trop tortueux, dans 6 mois on saurait plus pourquoi on a fait ça.

#8

Updated by Mikaël Ates about 1 month ago

J'utilise le plus souvent "Contient les permissions des rôles" et si une devait disparaître je préfèrerais effectivement que ce soit "Contient les membres des rôles".

Mais le côté informatif apporté par "Contient les membres des rôles" reste important et ne devrait pas disparaître je trouve. Ce serait donc peut-être juste ne plus le rendre éditable.

Et au final je trouve que passer "Contient les permissions des rôles" dans les paramètres "standards" et laisser "Contient les membres des rôles" dans les paramètres avancée est une bonne réponse.

Mais aussi, je n'ai pas eu de demandes ou d'incompréhension récentes sur ces sujets par des clients.

#9

Updated by Paul Marillonnet 18 days ago

  • Assignee set to Paul Marillonnet
  • Status changed from Nouveau to En cours

Mikaël Ates a écrit :

Et au final je trouve que passer "Contient les permissions des rôles" dans les paramètres "standards" et laisser "Contient les membres des rôles" dans les paramètres avancée est une bonne réponse.

Je vais proposer quelque chose qui va en ce sens.

#10

Updated by Paul Marillonnet 18 days ago

Et j’en appelle à votre avis.

J’étais parti pour [A] styler l’entrée "Contient les membres des rôles" comme les autres de cette section de paramétrage avancé dont elle fait maintenant parti.
Je me dis maintenant que ce n’est pas une bonne chose, que ça va être moche pour un Publik où de nombreux rôles héritent d’un même, car je ne suis pas certain que cette interface à base de '+' et '-' se prête à la gestion d’une liste volumineuse.

Je m'étais dit tant pis, qu’on pourrait plutôt faire le cheminement inverse et [B] adapter les interfaces de "Est géré par le(s) utilisateur(s)" et "Est géré par le(s) rôle(s)" pour qu’elle ressemblent à celle de la gestion de l’héritage de rôles, mais je ne suis pas convaincu non plus.

Enfin la troisième option, i.e. [C] bouger ce bout d’interface dans la partie pliable de paramétrage avancé ne me convainc pas non plus (cf capture).

Bref, indécision. Un avis sur la question ? Plutôt [A], [B] ou [C] ?

#11

Updated by Stéphane Laget 17 days ago

Le débat initial portait sur la terminologie "parent" / "enfant", cela a été réglé en mettant :
  • Contient les membres des rôles
  • Contient les permissions des rôles

la situation actuelle (= celle actuellement sur la recette, que je remets en pj) me parait tout à fait satisfaisante.

#12

Updated by Pierre Cros 17 days ago

Je réponds pas mais je reviens sur parents et enfants.

"hérite des permissions de" tu y vois des rôles parents, j'y vois des rôles enfants #56626

#13

Updated by Paul Marillonnet 17 days ago

Stéphane Laget a écrit :

Le débat initial portait sur la terminologie "parent" / "enfant", cela a été réglé en mettant […]

Oui, ce n’est pas sur la terminologie mais sur l’interface que portait ma question. Comme tu le dis, on peut aussi décider que l’interface actuelle convient très bien.

#14

Updated by Mikaël Ates 17 days ago

Question interface la solution actuelle va bien.

Peut-être juste les paramètres "Est géré par le(s) utilisateurs(s)" et "Est géré par le(s) rôle(s)" que je trouve à leur place dans les paramètres avancés gagneraient à devenir éditables de façon standard.

#15

Updated by Paul Marillonnet 17 days ago

Pierre Cros a écrit :

Je réponds pas mais je reviens sur parents et enfants.

"hérite des permissions de" tu y vois des rôles parents, j'y vois des rôles enfants #56626

Oui c’est juste une convention à adopter. Pour référence, la documentation du NIST à ce sujet, dont la terminologie est reprise dans pas mal d’implémentations RBAC, adopte la convention "contient les permissions de" -> "roles parents".

(Voir par exemple Inheritance properties of role hierarchies, page 7 ; ou cf capture).

#16

Updated by Paul Marillonnet 17 days ago

Mikaël Ates a écrit :

Peut-être juste les paramètres "Est géré par le(s) utilisateurs(s)" et "Est géré par le(s) rôle(s)" que je trouve à leur place dans les paramètres avancés gagneraient à devenir éditables de façon standard.

Je trouve l’interface actuelle pour ces deux éléments bien adaptée à la gestion d’une liste de taille modérée.

Est-ce qu’on a des exemples d’instance où elle ne serait pas adaptée, car la liste pour l’un de ces deux éléments est trop conséquentes (genre la liste des utilisateurs ou des rôles est repliées sur plusieurs lignes, il faut taper un <CTRL>+F pour voir si un rôle ou un usager s’y trouve, ou que sais-je encore).

#17

Updated by Emmanuel Cazenave 17 days ago

Mikaël Ates a écrit :

Mais aussi, je n'ai pas eu de demandes ou d'incompréhension récentes sur ces sujets par des clients.

Je ne peux pas m'empêcher d'y mettre mon grain de sel, parce que la terminologie de cet écran me perd encore, même après tout ce temps.

  • "Contient les permissions des rôles : " : c'est le seul truc que je trouve clair
  • sauf quand c'est vide où le "Ce rôle n’a pas de parents." commence à me perdre
  • "Contient les membre des rôles" + "ce rôle n'a pas d'enfant", au secours

Je crois que ce qui me perd c'est la terminologie parent/enfant, que je trouve très contre intuitive ici. Et le fait que "contient les membres des rôles" n'évoque pas du tout la situation inverse de "Contient les permissions des rôles" toute introduisant une nouvelle notion "les utilisateurs".

Je serai pour ne plus utiliser la terminologie parent/enfant, et pour remplacer "contient les membres des rôles" par un truc du genre "est inclus dans les rôles", dans l'idée que "être inclus" c'est un peu l'inverse de "contenir".

#18

Updated by Frédéric Péters 17 days ago

Et que ça ne soit pas juste une modification de la traduction, que les chaines natives soient également adaptées, parce que ce décalage participe à la confusion (genre on ajoute une chaine et paf on la traduit vite fait en "Ce rôle n'a pas d'enfants." et paf ça ne correspond pas à ce qu'on veut).

#19

Updated by Paul Marillonnet 17 days ago

Ok, un souci de terminologie avant tout oui. Il faut laisser tomber cette histoire de parents/enfants.
Je serai pour inverser les deux listes, en conservant dans l’intitulé de la seconde l’idée d’héritage de permissions. Ce serait quelque chose comme :

  • Contient les permissions des rôles :
    -> Ce rôle ne contient les permissions d’aucun autre rôle.
  • Accordes ses propres permissions aux rôles :
    -> Ce rôle n’accorde ses propres permissions à aucun autre rôle.

(cf capture pour la version pas encore traduite)

Il me semble que c’est plus clair comme ça.

#21

Updated by Benjamin Dauvergne 17 days ago

  • Status changed from Solution proposée to Solution validée

Oui ta nouvelle terminologie est très bien, go.

#22

Updated by Paul Marillonnet 17 days ago

  • Status changed from Solution validée to Résolu (à déployer)
commit 5ad1949b2d04d4d2a1d664d1d0c3de1de1f96d00
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Thu Sep 30 16:20:08 2021 +0200

    manager: provide a human-friendly rbac inheritance terminology (#56638)
#23

Updated by Frédéric Péters 9 days ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF