QGIS » AsgardMenu

Si l'idée est que chaque utilisateur puisse personnaliser son menu en excluant des blocs, des niv1 voire niv2 et/ou des schémas, alors ça ne peut être stocké que dans le QGIS3.ini. Avoir dans PG une table que n'importe qui pourrait modifier contenant le paramétrage de chaque utilisateur serait très compliqué à gérer et je ne vois pas vraiment la plus-value. Sinon, récupérer dans le QGIS3.ini des listes de valeurs à exclure dans la requête serait facile à faire. J'étais un peu inquiète sur l'effet en matière de performance sous PG 11 et inférieur qu'aurait l'ajout de conditions dans la sous-requête asgard_relations (dont j'avais dû retirer la condition sur relkind, si tu te souviens, parce qu'elle faisait exploser le temps de calcul), mais c'est bon, j'ai fait le test et ça ne pose pas de problème.

Il s'agirait de réécrire la sous-requête avec quelque chose de ce genre :

asgard_relations AS(
    SELECT
        asgardmenu_metadata.nom_schema,
        asgardmenu_metadata.bloc,
        asgardmenu_metadata.niv1,
        asgardmenu_metadata.niv2,
        pg_class.relname::text,
        pg_class.relkind::text,
        obj_description(pg_class.oid, 'pg_class') AS table_comment,
        asgardmenu_metadata.permission
    FROM pg_catalog.pg_class
        JOIN z_asgard.asgardmenu_metadata
            ON pg_class.relnamespace::regnamespace::text = quote_ident(asgardmenu_metadata.nom_schema)
    WHERE has_table_privilege(pg_class.oid, 'SELECT')
        AND has_schema_privilege(pg_class.relnamespace, 'USAGE')
        AND NOT coalesce(niv1, '') = ANY (%(aexclusionniv1)s)
        AND NOT coalesce(niv2, '') = ANY (%(aexclusionniv2)s)
        AND NOT nom_schema = ANY (%(aexclusionschema)s)
        AND NOT coalesce(bloc, '') = ANY (%(aexclusionbloc)s)
)

En ajoutant bien sûr les paramètres aexclusionniv1, aexclusionniv2, aexclusionschema et aexclusionbloc dans cur.execute, qui contiendront respectivement la liste des niv1, niv2, schémas et blocs à exclure, ou une liste vide s'il n'y a pas d'exclusion. Les listes python sont automatiquement converties en ARRAY et le fait d'utiliser l'opérateur ANY fait que les listes vides ne devraient pas poser de problème.

Maintenant, si l'idée était que l'ADL définisse une série de profils stockés dans une table PG, alors je me demande si complexifier en créant ce mécanisme supplémentaire a vraiment un sens, alors qu'il en existe déjà un à peu près équivalent : le fait que seul le patrimoine accessible au rôle de connexion soit visible dans AsgardMenu. Si l'ADL veut que certains utilisateurs ne voient que les données habitat, alors il peut créer un rôle de connexion habitat.defaut membre d'un rôle de groupe g_habitat qui ne verra que les données qui vont bien et faire en sorte que ses utilisateurs passent par ce rôle pour AsgardMenu. C'est une méthode sur laquelle nous pourrions insister dans la documentation.

Petite précision : avec la sous-requête asgard_relations modifiée comme ci-avant, il faudra avoir "" dans la liste des exclusions pour exclure les schémas sans bloc, sans niv1 ou sans niv2 (évidemment pas sans nom de schéma vu que ce n'est pas possible).

Pour la variante avec des profils type. En fait, oublie ce que j'ai écrit avant, ce n'est vraiment pas une bonne idée d'encourager les services à créer davantage de rôles de connexion non individuels.

On peut faire beaucoup plus propre : proposer un troisième paramètre définissable pour chaque connexion, en plus d'_alias_ et active, qui permette de spécifier un rôle de groupe à endosser pour la connexion. Si ce paramètre est spécifié, il s'agira juste d'ajouter un SET ROLE au début de la grande requête de récupération des données pour qu'elle s'exécute avec le rôle en question et non avec le rôle de connexion de l'utilisateur.

Dès lors, pour reprendre l'exemple précédent, l'ADL pourra créer un rôle de groupe thématique qui n'accède qu'à des données habitat et en rendre membre certains de ses utilisateurs, voire g_consult (ou consult.defaut) s'il s'agit d'un rôle de lecture. Ensuite il configure une connexion dans qgis_global_settings.ini en spécifiant dans le paramétrage d'AsgardMenu que son rôle de groupe thématique habitat doit être utilisé pour cette connexion. Et il peut faire ça pour autant de profils type qu'il le souhaite, puisque rien n'empêche dans QGIS de définir 15 fois la même connexion avec les mêmes paramètres tant que le libellé est différent.

Bonjour,
Je soumets une autre idée à votre expertise...
Asgard Menu utilise une requête assez consommatrice de ressources pour récupérer les informations des bases de données. Cette requête est lancée à chaque connexion avec un temps de réponse important.
Ne serait-il pas plus rapide d'avoir une requête matérialisée sur chaque base, actualisée grâce un trigger quotidien. En effet les bases ne devraient pas évoluer à un rythme nécessitant une mise à jour fréquente.
Cette requête et son trigger pourrait être intégrés à l'extension Asgard.

PS : l'idée des groupes thématiques ne serait pas forcément remise en question avec une VM.

Bonjour Michel,

Passer par une vue matérialisée ne me semble pas envisageable. Indépendamment de la question de sa fréquence d'actualisation (il me semble qu'un utilisateur voudra voir immédiatement apparaître les objets qu'il vient de créer, pas attendre 24h), le principal problème est que le contenu du menu dépend des droits de l'utilisateur, ainsi que du paramétrage qu'il a défini dans AsgardMenu. En somme, il nous faudrait avoir autant de vues matérialisées que d'utilisateurs...

Sur ces questions de performance, je pense que nous devrions attendre d'avoir des retours en situation réelle pour voir si des mesures supplémentaires s'imposent. Un temps d'exécution de la requête de quelques secondes sur une base à 30000 tables/vues et 500 schémas ne me paraît pas catastrophique, loin de là, par contre j'aimerais effectivement bien savoir ce que ça donne sur des serveurs partagés lorsque la requête est exécutée simultanément par un potentiellement grand nombre d'utilisateurs.

Il faudrait discuter un peu plus sur la façon pour l'ADL d'accorder des droits uniquement sur des données thématiques pour un rôle de groupe.

Dans mon premier test je crée un rôle de groupe habitat il faut que je lui accorde des droits au minimum USAGE sur les schémas souhaités + droit SELECT sur les tables et en plus le droit U Sur le schéma z_asgard et SELECT sur la vue AsgardMenu_metadata

Mais du coup se sont des manips sous pgadmin pas facile à expliquer. Peut-être que je rate quelque chose de beaucoup plus simple ?!

L'idée serait plutôt que le rôle habitat soit le producteur / éditeur / lecteur ou un membre du rôle avec la fonction adaptée pour tous les schémas qui doivent apparaître dans le menu (avec les bons droits) + lecteur ou membre du lecteur de z_asgard. Et il ne doit avoir aucun droit sur les autres schémas.

Dans l'absolu, il n'y a pas besoin de passer par pgAdmin pour ça. Mais on parle d'imbrications de rôles qui risquent de paraître assez conceptuelles à certains, surtout sans outil pour les visualiser. AsgardManager ne montre à ce stade que les ascendants et descendants directs, peut-être qu'il faudrait aller plus loin...

Et comme d'une manière générale on ne voudra pas que les rôles qui servent aux profils soient membres de g_consult, il faut effectivement penser à les rendre membres du lecteur de z_asgard, ce qui est une source de difficulté supplémentaire... En fait, peut-être que si on met ça en place il faudra revenir sur le choix qu'on avait fait de donner à g_consult et pas à public des droits de lecture implicites sur z_asgard.

Quoi qu'il en soit, je ne vois pas ces SET ROLE comme une solution magique à tous les problèmes, juste une possibilité supplémentaire. Si c'est facile à implémenter dans AsgardMenu, alors ça peut être intéressant de le proposer, si c'est trop compliqué peut-être qu'il vaut mieux se contenter du seul système d'exclusion pour le moment.

Bonjour Leslie,

Je ne suis toujours pas sûr de bien comprendre... Pour éclaircir mes idées, mettons que nous avons deux schémas schema1 et schéma2 et que l'on ne s'intéresse qu'à des droits en lecture.
Je veux avoir un profil générique g_consult qui accède en lecture aux deux schémas et un profil métier1 qui n'accède en lecture qu'à schéma1.
L'idée de base serait de mettre g_consult comme lecteur des deux schémas, mais du coup je ne vois pas comment rendre metier1 seulement lecteur de schéma1.
Une autre possibilité me semble être que ce soit metiers1 qui soit lecteur de schéma1 et que g_consult soit membre de métier1, mais çà me semble compliquer pas mal la gestion des droits et ce n'était pas l'esprit de Asgard.
Implémenter un SET ROLE dans AsgardMenu n'est pas compliqué, mais c'est la gestion sous-jacente à mettre en place (avec AsgardMAnager ?) qui me semble plus difficile.