QGIS » ASGARD

En fait un membre de g_gb_admin_delegue voir les schémas de la nomenclature dans la vue avec un
select * from z_admin_delegue.gestion_schema_usr
je pense qu'il ne devrait pas les voir...

Il faudrait également que pour tous les schémas seuls les membres de g_gb_admin puissent modifier le champ nomenclature.

A mon avis, la nomenclature est fixe et non modifiable à l'image du plan de classement COVADIS. On peut enrichir le plan de classement, décider de ne pas entièrement le mettre en œuvre, mais pas de retirer un schéma de la nomenclature de celle-ci.

Pris en compte dans asgard_5_triggers_v3.sql (lignes 170 à 193).
https://collab.din.developpement-durable.gouv.fr/sites/espace-drc/Documents%20partages/GT%20PostGIS/Gestion%20des%20droits%20-%20Prototype/asgard_5_triggers_v3.sql

-> sur un UPDATE, dès lors que OLD ou NEW.nomenclature vaut True, toute modification des champs nomenclature, niv1, niv1_abr, niv2, niv2_abr et nom_schema est interdite si elle n'est pas réalisée par un membre du groupe g_gb_admin ;

-> sur un INSERT NEW.nomenclature ne peut valoir True que si un membre de g_gb_admin est à l'origine de l'opération ;

-> les DELETE avec OLD.nomenclature valant True étaient déjà interdits. À noter qu'il reste possible pour l'ADL de basculer d'abord nomenclature sur False puis supprimer les lignes et il me semble que c'est une bonne chose. Tous les services n'interviennent pas sur toutes les thématiques et n'auront pas nécessairement envie de s'embarrasser de lignes correspondant à des schémas dont ils savent qu'ils n'auront jamais l'usage.

Par contre, je ne comprends pas bien pourquoi g_gb_admin devrait être le seul à voir les schémas de la nomenclature (pas que ce soit dur à mettre en oeuvre, sinon).

OK on verra plus tard avec les utilisateurs s'ils souhaitent que tout le monde voit les schémas de la nomenclature dans la vue gestion_schema_usr.

Pas exactement tout le monde non plus :
- pour les schémas créés, seulement les membres du groupe producteur - l'ADL étant libre de décider quel rôle producteur il utilise et qui en est membre ;
- pour les schémas non créés, seulement ceux qui ont le privilège CREATE sur la base.

Sur le deuxième point, je ne mesure peut-être pas tous les tenants et aboutissants, cependant on parle là-aussi d'utilisateurs triés sur le volet par l'ADL - voire d'aucun utilisateur si l'ADL n'a pas souhaité déléguer la création de schémas. Je n'ai pas non plus l'impression que créer le schéma c_agri_environnement soit une opération plus sensible que p_mon_application. Lorsque le schéma est créé, il n'y a encore rien dedans et ce sont les rôles désignés qui décident de qui pourra le voir et accéder à son futur contenu, pas le fait qu'il appartienne ou non à la nomenclature.

Par contre, lorsque j'ai écrit le filtre de la vue, j'ai considéré que tous les utilisateurs avec CREATE sur la base devaient voir l'ensemble des schémas non créés pour éviter le problème suivant.

[BON] Si x, qui a CREATE sur la base, lance un CREATE SCHEMA sur un schéma qui apparaît dans les vues gestion_schema_usr/etr avec creation = False, alors le schéma est créé et l'event trigger execute un UPDATE qui bascule creation sur True pour ledit schéma.

[MAUVAIS] Si le même x lance un CREATE SCHEMA sur un schéma qui apparaît dans gestion_schema avec creation = False mais qui, pour une raison quelconque, n'apparaît pas dans les vues, alors il se retrouve avec une erreur de non respect de la contrainte d'unicité sur nom_schema qui sera complètement incompréhensible pour lui. Car l'event trigger sur CREATE SCHEMA scanne la vue, ne trouve rien et en déduit que le schéma n'est pas répertorié dans gestion_schema et lance un INSERT au lieu d'un UPDATE. C'est dans la même veine que l'erreur qu'avait signalée Michel - en moins vicieux tout de même (la sienne, je ne l'avais vraiment pas vue venir) - et la principale difficulté est qu'il est impossible d'envoyer un message d'erreur propre à l'utilisateur, car si lui ne voit pas la ligne, alors les triggers et event triggers non plus.

Par conséquent, si on voulait verrouiller davantage les changements sur les schémas de la nomenclature (c'est à dire empêcher de modifier les rôles, puisque c'est à peu près tout ce qu'il reste possible de faire quand on n'est pas membre de g_gb_admin à ce stade), il serait préférable de le faire via le trigger on_modify_gestion_schema_before, en complétant le bloc "VERROUILLAGE DES CHAMPS LIES A LA NOMENCLATURE". Là au moins on peut envoyer des messages d'erreur clairs.