Projet

Général

Profil

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

Ajouté par Paul Marillonnet il y a plus d'un an. Mis à jour il y a environ un an.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
22 décembre 2022
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

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

Lié à Authentic 2 - 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’usagerFermé21 décembre 2022

Actions
Lié à Authentic 2 - Development #71275: contrôle d’accès : gérer l’appartenance à des collectivités pour les clients d’APIFermé14 novembre 2022

Actions

Révisions associées

Révision 16ba2802 (diff)
Ajouté par Paul Marillonnet il y a environ un an

models: drop non-nullity constraint ou API clients' OU (#72703)

Révision 88fe8e14 (diff)
Ajouté par Paul Marillonnet il y a environ un an

manager: force api client ou assignment for local admins (#72703)

Révision ed292f65 (diff)
Ajouté par Paul Marillonnet il y a environ un an

manager: filter api client's assignable roles depending on its OU (#72703)

Révision 1d668a16 (diff)
Ajouté par Paul Marillonnet il y a environ un an

OU consistency check between api client and roles at validation (#72703)

Révision de60d04f (diff)
Ajouté par Paul Marillonnet il y a environ un an

translation update (#72703)

Historique

#1

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é
#2

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é
#3

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

#4

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.

#5

Mis à jour par Paul Marillonnet il y a plus d'un an

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.

#6

Mis à jour par Paul Marillonnet il y a plus d'un an

(Et oui, j’oubliais, c’est basé sur la branche de #72688.)

#7

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.)

#8

Mis à jour par Robot Gitea il y a environ un an

Paul Marillonnet (pmarillonnet) a ouvert une pull request sur Gitea concernant cette demande :

#9

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 :

#10

Mis à jour par Paul Marillonnet il y a environ un an

  • Statut changé de Solution validée à Résolu (à déployer)
#11

Mis à jour par Transition automatique il y a environ un an

  • Statut changé de Résolu (à déployer) à Solution déployée
#12

Mis à jour par Transition automatique il y a 11 mois

Automatic expiration

Formats disponibles : Atom PDF