Produits Entr'ouvert » Authentic 2

J'ai choisi de retourner deux liste : une pour les membres directs et une pour tous les membres (directs + hérités).
Les utilisateurs renseignés dans ces deux listes contiennent les champs username , email , first_name , last_name et uuid .

Pour tester :

curl https://LOGIN:PASSWD@authentic.dev.publik.love/api/roles/

(patch qui corrige juste le test)

je ne vois pas bien comment deux valeurs identiques peuvent renvoyer des listes différentes

cf https://www.django-rest-framework.org/api-guide/relations/#custom-relational-fields
moi aussi je suis bluffé par la magie de DRF, qui j'imagine fait de l’introspection sur le nom de la variable.

tu charges une API déjà existante,

Oui, dans l'idée de continuer à utiliser DRF. Par exemple cette URL retourne également les membres du groupe :

curl https://LOGIN:PASSWD@authentic.dev.publik.love/api/roles/UUID_DU_ROLE

et que ça pourrait l'alourdir considérablement ?

Oui, est-ce à dire que ce que l'on souhaite ici c'est plutôt d'ajouter 2 nouvelles API roles/X/members et roles/X/all_members ?

Voilà.

on ne peut pas vraiment reprendre UsersAPI tel quel, il faut ignorer tout ce qui permet de créér/modifier un utilisateur, donc juste les endpoints list et retrieve.

cf https://www.django-rest-framework.org/api-guide/viewsets/ :

roles_members = RolesMembersAPI.as_view({'get': 'list'})

(J'ai l'impression que retrieve devra nécessairement faire l'objet d'un nouveau endpoint /api/roles/<role_uuid>/members/<user_uuid>,
et que l'on s'éloigne alors du sujet de ce ticket qui vise à obtenir une liste.)

De ma compréhension de DRF, on n'a pas de quoi gérer les routers complexes : https://www.django-rest-framework.org/api-guide/routers/#drf-nested-routers
Et donc je n'ai pas réussi à factoriser pour ne pas avoir à introduire des nouvelle URLs comme pour listers les membres, et à avoir un unique routeur comme c'est fait pour UsersAPI.

• GET roles/UUID/members/[?nested=true]
• GET roles/UUID/members/UUID/[?nested=true]

• GET users/ :
  

  {
     "next" : null,
     "previous" : null,
     "results" : [
     ...
  

  
  ou
  

  {"next":null,"previous":null,"results":[]} 
  

• GET user/UUID/
  

  {
  ...
     "first_name" : "Nicolas",
     "first_name_verified" : false,
     "id" : 2,
     "is_active" : true,
  ...
  }
  

  
  ou
  

  {"result":0,"errors":{"detail":"Pas trouvé."}}
  

quelque chose de minimum et peu coûteux (i.e. sans les attributs étendus dans /members/ et l'utilisateur complet dans /members/<uuid>/),

J'ai simplifié le queryset utilisé en pensant que ça suffirait mais en fait non, ça ne change pas le rendu : par exemple la date de naissance est toujours retournée que avec GET users/.
(sur ce point je bloque)

Nicolas Roche a écrit :

De ma compréhension de DRF, on n'a pas de quoi gérer les routers complexes : https://www.django-rest-framework.org/api-guide/routers/#drf-nested-routers
Et donc je n'ai pas réussi à factoriser pour ne pas avoir à introduire des nouvelle URLs comme pour listers les membres, et à avoir un unique routeur comme c'est fait pour UsersAPI.

Ouaip je comprends comme toi. Ça aurait été plus joli d'introduire un viewset pour /api/roles/.../members/ mais ce sera pour une autre fois.

---

RolesMembersAPI.get_queryset(self)

C'est un peu moche, ici on peut juste utiliser directement role.all_members().

        qs = qs.filter(deleted__isnull=True)

deleted n'existe plus.

---

            perm = 'a2_rbac.change_role'

Ça c'est un bug qui traîne, la permission pour la gestion des membres s'appelle 'manage_members' maintenant.

Je serais plutôt pour que les checks restent simples et soient déplacés dans chaque méthode get/post/delete plutôt que de jouer avec request.method, 2 fois.

Remarques prises en compte.

perm = 'a2_rbac.change_role'

traité dans 0002 (qui vient s'ajouter)

RolesMembersAPI.get_queryset(self)
C'est un peu moche, ...

Oui, c'est tordu de rentrer dans la classe RolesMembersAPI par ici,

... ici on peut juste utiliser directement role.all_members().

mais je rajoute le 'if' sur 'nested' pour que sur GET roles/UUID/members/UUID/ on ne retourne pas un utilisateur uniquement membre indirect du groupe.

Nicolas Roche a écrit :

Remarques prises en compte.

perm = 'a2_rbac.change_role'

traité dans 0002 (qui vient s'ajouter)

Oui mais non la gestion des rôles eux même (nom, slug, etc..) c'est bien change_role, la permission ne doit changer que dans RoleMembershipAPI.

... ici on peut juste utiliser directement role.all_members().

mais je rajoute le 'if' sur 'nested' pour que sur GET roles/UUID/members/UUID/ on ne retourne pas un utilisateur uniquement membre indirect du groupe.

À voir si c'est une bonne idée mais ok.

Oui mais non la gestion des rôles eux même (nom, slug, etc..) c'est bien change_role, la permission ne doit changer que dans RoleMembershipAPI.

Merci pour ta vigilance.

commit b21d5a56b15d1fdf615919fbb93b614feac92193
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Mon Feb 22 23:13:38 2021 +0100

    tests: copy/paste users tests to member users api (#50889)

commit ed01a4e8c34653f74217ca42cdb4bd68b45b1432
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Mon Mar 22 10:15:15 2021 +0100

    api: add list and retrieve role member(s) api (#50889)

commit 852655fb95af9850a53b4430169719f4de3960d5
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Mon Mar 22 11:30:53 2021 +0100

    api: upgrade change_role permission to manage_members (#50889)