Anomalie #327
ferméSchémas dont un super-utilisateur est producteur
0%
Description
Premier test que je fais ce soir : appuyer sur le bouton Appliquer sur le formulaire du premier schéma venu.
AsgardManager me renvoie l'erreur suivante :
Pourtant le schéma existe et je me connecte avec un rôle membre de g_admin, qui est apparemment le producteur (et donc le propriétaire) du schéma.
Sauf que non, avec vérification sur pgAdmin, c'est ici le super-utilisateur postgres qui se trouve être propriétaire du schéma (et le producteur renseigné dans gestion_schema_usr, comme il se doit). Si c'est g_admin qui apparaît dans le formulaire, c'est parce que postgres n'est pas dans la liste des rôles disponibles, car AsgardManager n'affiche que les rôles dont l'utilisateur a l'usage et mon rôle de connexion n'a pas de droits sur postgres. Comme g_admin est le premier de la liste, c'est lui qui se retrouve affiché. D'ailleurs, si je passe sur le formulaire du schema z_asgard, dont g_admin_ext est producteur, puis reviens sur mon schéma c_agri_agroalimentaire, c'est maintenant g_admin_ext qui apparaît à la place.
Avec un rôle lambda, le schéma en question n'apparaîtrait pas dans la vue gestion_schema_usr et AsgardManager le mettrait (un peu abusivement - cf. ticket #301) dans les "schémas externe à Asgard". Ici il se trouve bien dans le bloc c, car, par principe, la vue gestion_schema_usr montre tous les schémas référencé aux membres de g_admin, y compris lorsqu'ils n'ont pas de droits dessus. Il paraissait important que l'ADL ait une vision exhaustive de son patrimoine sans avoir à se connecter avec un rôle super-utilisateur.
Bref, je pense qu'il est essentiel de traiter ce problème, car beaucoup de services auront des schémas dont le rôle adl (super-utilisateur "métier" des serveurs EOLE) est propriétaire. Si les ADL se connectent avec leur rôle de connexion individuel qui est seulement membre de g_admin, ils vont se retrouver dans cette situation et risquent de ne pas comprendre ce qui se passe.
L'idée est bien qu'ils se rendent compte qu'il va leur falloir se reconnecter avec un autre rôle s'ils veulent agir sur le schéma.
C'est peut-être un point à discuter collectivement, mais je pense qu'il y a deux choses à faire :
1. le producteur réel du schéma doit apparaître dans la liste des rôles, même si l'utilisateur n'est pas autorisé à en faire usage ;
2. si le producteur réel n'est pas un rôle utilisable, l'utilisateur (présumé membre de g_admin pour cette première version) devrait uniquement pouvoir modifier les champs niv1, niv2, niv1_abr et niv2_abr. L'idéal serait qu'il y ait quelque part sous/dans/au-dessus du formulaire un message explicite lui disant : "Vous n'êtes pas membre du rôle producteur de ce schéma.".
Le 1. est vraiment impératif, on ne peut pas donner à l'utilisateur de fausses informations. Le 2. serait souhaitable pour la première version, mais on pourrait envisager des solutions un peu drastiques dans un premier temps - comme le fait de bloquer purement et simplement la validation/griser tout le formulaire.
Fichiers
Mis à jour par Leslie Lemaire il y a plus de 4 ans
- Fichier nv_message_erreur_acces.png nv_message_erreur_acces.png ajouté
Entre temps, j'ai ajouté des contrôles d'erreur dans ASGARD pour ces cas où g_admin tente de modifier un schéma appartenant à un super-utilisateur (ainsi que le supprimer, le créer, le référencer...).
L'utilisateur a maintenant des messages d'erreurs plus parlants. Ici :
Donc je me dis qu'un cas comme celui-là, somme toute rare, ne mérite sans doute pas que tu mettes en place des contrôles surfaciques (ce que j'évoquais en 2.). Mieux vaut récupérer proprement les erreurs d'ASGARD, que je peux d'ailleurs encore améliorer si besoin.
Mis à jour par Didier LECLERC il y a plus de 4 ans
- Statut changé de Nouveau à Fermé
Corrigé le point 1 :le 31/08/2020
Mis à jour par Didier LECLERC il y a plus de 4 ans
- Version cible mis à ASGARD MANAGER version 1.0.0