Project

General

Profile

Development #59664

Accorde ses propres permissions aux rôles : migré vers menu burger

Added by Alexis Mathias 5 months ago. Updated 5 months ago.

Status:
Fermé
Priority:
Normal
Category:
-
Target version:
-
Start date:
14 Dec 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

En formation avec Stéphane à Roanne.

L'accès a "Accorde ses propres permissions aux rôles" a migré vers le menu burger et n'est pas accessible directement.
MAJ à venir apparemment (uniquement en recette)

Il est plus difficile à expliquer aux futurs utilisateurs.

Merci de voir si on peut revenir en arrière.


Files


Related issues

Related to Authentic 2 - Development #57955: tableau affichant les membres "directs" d'un rôleFermé18 Oct 2021

Actions

Associated revisions

Revision bd437dda (diff)
Added by Valentin Deniaud 5 months ago

manager: handle data-pk row attribute at view level (#59664)

Revision 84bc4a1a (diff)
Added by Valentin Deniaud 5 months ago

manager: add child roles in role members view (#59664)

History

#1

Updated by Frédéric Péters 5 months ago

Merci de voir si on peut revenir en arrière.

Revenir en arrière non, aller en avant oui.

#2

Updated by Valentin Deniaud 5 months ago

#3

Updated by Valentin Deniaud 5 months ago

Yep, développement arrivé hier en recette, il y a le temps d'en faire un truc qui convient à tout le monde avant l'arrivée en prod.

Plus que les discussions du ticket lié il faut lire/continuer celles de #56638.

#4

Updated by Frédéric Péters 5 months ago

On a désormais en effet un truc bizarre, pour ajouter un utiisateur dans le rôle, ça passe par la zone "Ajouter un utilisateur" qui est sous le tableau, alors que pour ajouter un rôle dans le rôle, ça passe par le menu burger.

Pour le premier, avec une sélection d'un utilisateur directement dans la page, pour l'autre avec un tableau des rôles où piocher ceux qui doivent être ajoutés.

Je serais pour avoir sous le tableau les deux, soit en les superposant,

Ajouter un utilisateur :  [ ............................... |v]  [Ajouter]
Ajouter un rôle :         [ ............................... |v]  [Ajouter]

Soit en ayant un champ de recherche combiné (ce qui aurait ma préférence),

Ajouter au rôle :  [ .(recherche usagers et rôles)......... |v]  [Ajouter]
#5

Updated by Benjamin Dauvergne 5 months ago

Frédéric Péters a écrit :

Soit en ayant un champ de recherche combiné (ce qui aurait ma préférence),

[...]

C'est ce que j'avais évoqué dans #57955, ça a toujours ma préférence aussi :

je suppose qu'il faut penser ça dans une refonte de l'action "Ajouter un membre" qui dans un même élan devrait pouvoir traiter les rôles et les usagers.

Option simple encore une fois, pas touche à cette action et à la place je déplace l'action pour ajouter un rôle comme membre dans le menu kebab, il me semble que c'est assez cohérent avec les discussions de #56638.

#6

Updated by Valentin Deniaud 5 months ago

Benjamin Dauvergne a écrit :

Frédéric Péters a écrit :

Soit en ayant un champ de recherche combiné (ce qui aurait ma préférence),

C'est ce que j'avais évoqué dans #57955, ça a toujours ma préférence aussi :

Et moi qui vais m'y coller j'ai regardé le code et ma préférence ça serait d'avoir deux champs distincts pour rôles et utilisateurs, mais bon puisqu'il y a consensus allons-y comme ça.

Techniquement ça serait OK de proposer un patch qui n'utilise pas django-select2 ? On perdrait deux choses, premièrement la mutualisation du code entre les champs, mais ce nouveau champ serait suffisamment différent pour que ce ne soit pas intéressant. Deuxièmement, le cache, là je n'arrive pas à savoir si ne pas en avoir poserait des vrais problèmes de perf ou pas du tout.

#7

Updated by Frédéric Péters 5 months ago

(perso totalement pour retirer django-select2, c'est une dépendance qui ne va pas poser problème pour bullseye mais que je voyais déjà amener des ennuis plus loin).

#8

Updated by Valentin Deniaud 5 months ago

  • Assignee set to Valentin Deniaud
#9

Updated by Benjamin Dauvergne 5 months ago

Valentin Deniaud a écrit :

Techniquement ça serait OK de proposer un patch qui n'utilise pas django-select2 ? On perdrait deux choses, premièrement la mutualisation du code entre les champs, mais ce nouveau champ serait suffisamment différent pour que ce ne soit pas intéressant.

Je n'ai rien contre, si ça peut donner une base pour migrer le reste tant mieux.

Deuxièmement, le cache, là je n'arrive pas à savoir si ne pas en avoir poserait des vrais problèmes de perf ou pas du tout.

Je ne sais pas de quel cache tu parles; peux-tu expliciter ?

#10

Updated by Valentin Deniaud 5 months ago

Benjamin Dauvergne a écrit :

Je ne sais pas de quel cache tu parles; peux-tu expliciter ?

https://django-select2.readthedocs.io/en/latest/django_select2.html#module-django_select2.cache, utilisé par le widget https://django-select2.readthedocs.io/en/latest/django_select2.html#django_select2.forms.HeavySelect2Mixin. Actuellement on a déjà bricolé ça pour que ce ne soit plus l'objet queryset qui soit mis en cache mais juste le where de la requête. Mais tout bien réfléchi je ne sais même pas quel gain on a à faire ça.

#11

Updated by Benjamin Dauvergne 5 months ago

Valentin Deniaud a écrit :

Benjamin Dauvergne a écrit :

Je ne sais pas de quel cache tu parles; peux-tu expliciter ?

https://django-select2.readthedocs.io/en/latest/django_select2.html#module-django_select2.cache, utilisé par le widget https://django-select2.readthedocs.io/en/latest/django_select2.html#django_select2.forms.HeavySelect2Mixin. Actuellement on a déjà bricolé ça pour que ce ne soit plus l'objet queryset qui soit mis en cache mais juste le where de la requête. Mais tout bien réfléchi je ne sais même pas quel gain on a à faire ça.

J'ai l'impression que tu es embêté ici car on veut un sélecteur pouvant contenir deux modèles différents et que ça ne rentre pas dans le schéma de django-select2 : 1 field = 1 widget = 1 queryset = 1 modèle. Clairement ça ne sert à rien de reproduire quoi que ce soit de django-select2, il faut un champ spécifique qui ne peut pas être un ModelField (il faut passer l'information modèle + pk) et une vue AJAX spécifique pour renvoyer les réponses, il n'y a pas trop le choix, il n'y a aucun cache nécessaire. Pour moi la demande de virer django-select2 c'est forcément la demande d'avoir autant de vue AJAX que de champs select2 ou presque. Ce qui était sympa avec django-select2 c'est qu'une seule suffisait et ça marchait tout seul.

#12

Updated by Valentin Deniaud 5 months ago

Voilà bon pour relecture mais surtout à tester en local.

J'ai gardé une petite dépendance select2, le widget, pour ne pas avoir à me farcir de html ni de js mais on pourra facilement prendre ça à notre charge dans un second temps.

En plus de l'ajout de rôles via le champ select2, il fallait aussi gérer la suppression via le tableau.

#13

Updated by Benjamin Dauvergne 5 months ago

  • Status changed from Solution proposée to Solution validée
  • 0001: nickel
  • 0002: beau bordel, mais j'ai testé ça marche.
#14

Updated by Valentin Deniaud 5 months ago

  • Status changed from Solution validée to Résolu (à déployer)
commit 84bc4a1a56b47e0e4e5cf426c090f059bb41f27c
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Tue Jan 4 16:00:24 2022 +0100

    manager: add child roles in role members view (#59664)

commit bd437ddafb8807d4b788b8f054d9491554a4450b
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Mon Dec 20 16:40:44 2021 +0100

    manager: handle data-pk row attribute at view level (#59664)
#16

Updated by Pierre Cros 5 months ago

Chic mais il y a toujours l'entrée « Ajouter un rôle comme membre » dans le menu Burger, je pense qu'on pourrait la supprimer.

#17

Updated by Frédéric Péters 5 months ago

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

Updated by Stéphane Laget 5 months ago

Cela change bcp de nos habitudes.
Peut-être que "Voir tous les membres" devrait être coché par défaut.

#19

Updated by Frédéric Péters 5 months ago

En parallèle à #60271, pour répondre sur le lien dans le menu burger, j'ai cette proposition alternative, qui déplacerait le lien vers cette gestion "en masse" dans la page, sans être totalement convaincu. (je n'ai pas retrouvé dans les tickets les moments où cette possibilité de gestion en masse était notée comme utile).

#20

Updated by Pierre Cros 5 months ago

Pour moi il n'est même pas nécessaire d'ajouter le lien que propose Fred et qui rend le truc plus délicat à comprendre.

On tolère le fait que l'ajout se fasse nécessairement un par un pour les utilisateurs, on peut le tolérer pour les rôles aussi (l'ajout de plusieurs utilisateurs à un rôle est certainement un cas d'usage plus fréquent que l'ajout de plusieurs rôles à un rôle).

Si on veut prévoir quelque chose pour l'ajout de plusieurs rôles/utilisateurs, je suis d'avis qu'il faut traiter ça ensemble et dans un autre ticket.

#21

Updated by Transition automatique 3 months ago

Automatic expiration

Also available in: Atom PDF