Development #72703
/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
Fichiers
Demandes liées
Révisions associées
manager: force api client ou assignment for local admins (#72703)
manager: filter api client's assignable roles depending on its OU (#72703)
OU consistency check between api client and roles at validation (#72703)
translation update (#72703)
Historique
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à Development #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 ajouté
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à Development #71275: contrôle d’accès : gérer l’appartenance à des collectivités pour les clients d’API ajouté
Mis à jour par Paul Marillonnet il y a plus d'un an
- Assigné à mis à 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
Mis à jour par Paul Marillonnet il y a plus d'un an
- Sujet changé de /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 à /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.
Mis à jour par Paul Marillonnet il y a plus d'un an
- Fichier 0004-OU-consistency-check-between-api-client-and-roles-at.patch 0004-OU-consistency-check-between-api-client-and-roles-at.patch ajouté
- Fichier 0003-manager-filter-api-client-s-assignable-roles-dependi.patch 0003-manager-filter-api-client-s-assignable-roles-dependi.patch ajouté
- Fichier 0002-manager-force-api-client-ou-assignment-for-local-adm.patch 0002-manager-force-api-client-ou-assignment-for-local-adm.patch ajouté
- Fichier 0001-models-drop-non-nullity-constraint-ou-API-clients-OU.patch 0001-models-drop-non-nullity-constraint-ou-API-clients-OU.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
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.
Mis à jour par Paul Marillonnet il y a plus d'un an
(Et oui, j’oubliais, c’est basé sur la branche de #72688.)
Mis à jour par Paul Marillonnet il y a plus d'un an
(À 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.)
Mis à jour par Robot Gitea il y a environ un an
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
Mis à jour par Robot Gitea il y a environ un an
- Statut changé de Solution proposée à Solution validée
Serghei Mihai (smihai) a approuvé une pull request sur Gitea concernant cette demande :
Mis à jour par Paul Marillonnet il y a environ un an
- Statut changé de Solution validée à Résolu (à déployer)
Mis à jour par Transition automatique il y a environ un an
- Statut changé de Résolu (à déployer) à Solution déployée
models: drop non-nullity constraint ou API clients' OU (#72703)