Développement #72703
closed/manage/ : l’écran de gestion des clients d’API doit filtrer les rôles ajoutables au client en fonction de l’OU du client d’API
0%
Description
Une première étape du travail de cohérence des OUs des clients d’API dans le /manage/ est #72688, qui filtre les clients visibles et l’OU ajoutable au client en fonction du/des rôle(s) de gestion détenus par l’usager.
Une autre partie nécessaire, dont il est question ici, est d’utiliser cette même logique pour filtrer les rôles que l’usager peut ajouter au client d’API
Files
Updated by Paul Marillonnet over 3 years ago
- Related to Développement #72688: /manage/ : l’écran de gestion des clients d’API doit filtrer en fonction de l’OU du/des rôles de gestion détenus par l’usager added
Updated by Paul Marillonnet over 3 years ago
- Related to Développement #71275: contrôle d’accès : gérer l’appartenance à des collectivités pour les clients d’API added
Updated by Paul Marillonnet over 3 years ago
- Assignee set to Paul Marillonnet
Concrètement, les rôles liés à au moins une permission globale ou dans une OU autre que celle(s) du/des rôle(s) de gestion détenus par l’usager ne devraient pas apparaître parmi la liste des rôles ajoutables au client d’API
Updated by Paul Marillonnet over 3 years ago
- Subject changed from /manage/ : l’écran de gestion des clients d’API doit filtrer les rôles ajoutables au client en fonction de l’OU du/des rôles de gestion détenus par l’usager to /manage/ : l’écran de gestion des clients d’API doit filtrer les rôles ajoutables au client en fonction de l’OU du client d’API
Faisons plus simple : seuls les rôles pour lesquels role.ou == api_client.ou apparaissent dans la liste des rôles ajoutables au client.
Updated by Paul Marillonnet over 3 years ago
- File 0004-OU-consistency-check-between-api-client-and-roles-at.patch 0004-OU-consistency-check-between-api-client-and-roles-at.patch added
- File 0003-manager-filter-api-client-s-assignable-roles-dependi.patch 0003-manager-filter-api-client-s-assignable-roles-dependi.patch added
- File 0002-manager-force-api-client-ou-assignment-for-local-adm.patch 0002-manager-force-api-client-ou-assignment-for-local-adm.patch added
- File 0001-models-drop-non-nullity-constraint-ou-API-clients-OU.patch 0001-models-drop-non-nullity-constraint-ou-API-clients-OU.patch added
- Status changed from Nouveau to Solution proposée
- Patch proposed changed from No to Yes
0001 qui relève la contrainte de non-nullité sur l’OU du client d’API, car dorénavant si on souhaite un client qui tape dans l’API sur toutes les OU ça se matérialise par api_client.ou = None.
0002 qui empêche les admins locaux de créer un tel client d’API "global", en retirant l’option ou = None du formulaire d’ajout/d’édition.
0003 qui, à l’affichage du formulaire, filtre les rôles ajoutables à l’OU en fonction de l’OU d’appartenance du client.
0004 qui, à la validation du formulaire, vérifie la cohérence entre OU du client et OU des rôles ajoutés.
Updated by Paul Marillonnet over 3 years ago
(Et oui, j’oubliais, c’est basé sur la branche de #72688.)
Updated by Paul Marillonnet over 3 years ago
(À noter aussi qu’on pourrait ajouter à 0004 du JS qui rafraîchit la liste des rôles sélectionnés et celle des rôles disponibles dès que l’OU change dans le formulaire, mais j’ai pas tellement envie de me lancer là dedans. Si quelqu’un veut prendre, welcome. L’essentiel, pour moi, est de conserver la cohérence des OUs, tant pis si l’admin doit s’y reprendre à deux fois pour valider le formulaire.)
Updated by Robot Gitea about 3 years ago
Paul Marillonnet (pmarillonnet) a ouvert une pull request sur Gitea concernant cette demande :
- URL : https://git.entrouvert.org/entrouvert/authentic/pulls/7
- Titre : wip/72703-api-client-ou-roles-list
- Modifications : https://git.entrouvert.org/entrouvert/authentic/pulls/7/files
Updated by Robot Gitea about 3 years ago
- Status changed from Solution proposée to Solution validée
Serghei Mihai (smihai) a approuvé une pull request sur Gitea concernant cette demande :
Updated by Paul Marillonnet about 3 years ago
- Status changed from Solution validée to Résolu (à déployer)
Updated by Transition automatique about 3 years ago
- Status changed from Résolu (à déployer) to Solution déployée