Sources, applications, modules ?

[camillemonchicourt]

Il y a une certaine redondance entre les notions de Sources, d'applications, de modules et de types de contenus.

Ebauche de @gildeluermoz :

@TheoLechemia :

Ok pour moi.
Juste bien maintenir l'intégrité entre gn_meta.t_module et utilsateurs.t_application pour gérer les droits des modules

@camillemonchicourt :

Un besoin important est que l'on puisse gérer des modules internes et externes et tracer leurs données.

Un module externe pouvant être un outil WEB, listé dans la liste des modules dans GeoNature mais s'ouvrant dans un autre onglet car avec un FRONT déconnecté de celui de GeoNature (exemple de projet_suivi ou d'éventuels module GN1 que l'on garderait encore quelques temps). Cela pourrait aussi être d'autres protocoles dont le schema serait dans GN mais dont la saisie se ferait dans QGIS, LizMap ou autre.
Si je comprends bien, le champs URL servirait à ça. Pour les "modules" dont le front serait externe à GN, à ouvrir dans un nouvel onglet ?
C'est le fonctionnement qu'on avait dans GN1 dans t_sources.

Le terme de MODULE peut porter un peu à confusion car il laisse penser que cela ne contient que les modules GN mais à nous de clarifier ce que l'on appelle MODULE, sujet pas encore forcément clair et évident.

Pour les modules internes, il faut peut-être ajouter un champs pour enregistrer la route du module (occtax par exemple). Cela permettra de générer dynamiquement la liste des modules avec le lien vers leur interface interne. A moins que cela soit géré par ailleurs ?

On est tous assez favorable au fait de gérer l'activation/désactivation des modules dans la BDD, avec le champs ACTIVE que tu as ajouté. Mais si on le fait, il faut retirer le mécanisme actuel mis en place lors du workshop avec les gn_module_available et gn_module_enabled.

Si la synthèse contient des données saisies en internes et externes, doit-on (peut-on) lister aussi dans la table t_parents d'autres sources comme des BDD Access, Tableurs etc... ?
D'ailleurs au final, si on éclate en 2 tables, je parlerai plutôt de gn_synthese.t_sources plutôt que t_parents.
On a mis de l'héritage un peu partout donc t_parents porte plus à confusion je trouve.
C'est dans cette table que j'ajouterai un champs last_import, ou plutôt last_insert comme évoqué ici : #103

Mais je ne suis pas sur qu'il faille 2 tables ? Car là elles sont liées en 0-1 ?

Et pour l'intégrité entre gn_meta.t_modules et utilisateurs.t_applications j'y vois pas bien clair si on est en train de faire un doublon, et si il faut les dissocier ou les lier.

Au final là on retombe sur 3 tables qui font un peu la même chose mais pas vraiment.

Bref, beaucoup de questions et réflexions un peu en vrac pour faire avancer le sujet mais je n'y vois pas bien clair encore.

[camillemonchicourt]

En fait, en en recausant, en regardant en détail, ce sont bien des choses souvent nommés pareil, mais pas tout le temps et avec des usages bien différents :

• utilisateurs.t_applications (pour gérer les droits)
• synthese.t_sources (pour gérer les sources de données dans la synthèse interne ou externe à GN, remonter à la source, tracer le dernier import...)
• gn_meta.t_modules (pour gérer les modules de GeoNature avec leur URL ou route, leur picto, activer ou non)
• gn_core.bib_type_objects (pour lister les tables dans la BDD sur lesquels il y a du stockage vertical)

[camillemonchicourt]

Après discussion avec Théo, maintenant qu'on a un schéma gn_commons, on mettrait plutôt t_modules dans ce schéma plutôt que dans gn_meta et on ajouterait dans cette table une FK vers utilisateurs.id_application, un champ route, un champs active et un champ picto.

[gildeluermoz]

Oui ce schéma commons manquait.
Il y a potentiellement plusieurs éléments qui seraient mieux ici.
On va le faire au fur et à mesure.

[TheoLechemia]

Je m'occupe de créer t_modules, je vais en avoir besoin pour l'affichage/masquage des modules

[camillemonchicourt]

Le choix d'utiliser utilisateurs.t_applications ou gn_commons.t_modules peut aussi varier selon les contextes.

Si le besoin concerne uniquement GeoNature, il est privilégié d'utiliser gn_commons.t_modules car utilisateurs.t_applications est centré sur la gestion des droits et ne liste pas forcément tous les modules d'une instance GeoNature.

Cependant quand les besoins dépassent GeoNature, alors utilisateurs.t_applications est la seule référence permettant de lister les différentes applications.

Cela s'inscrit dans la discussion autour du besoin de pouvoir lier des nomenclatures avec des applications. Dans ce cas qui dépasse GeoNature, le rattachement est fait avec utilisateurs.t_applications dans une nouvelle table ref_nomenclatures.cor_application_nomenclature.

[camillemonchicourt]

La réflexion en cours sur la réintégration du CRUVED dans GeoNature (c9a70c7) aménera à ne plus lister tous les modules de GeoNature dans UsersHub.
On n'aurait plus qu'une application GeoNature dans UsersHub permettant de définir quels utilisateurs ont accès ou pas dans GeoNature. C'est ensuite côté GeoNature que serait défini plus précisément ce que chaque utilisateur peut voir/faire dans GeoNature.

A voir si ça pose un problème par rapport à ref_nomenclatures.cor_application_nomenclature si celle-ci avait vocation à limiter des nomenclatures à des modules particuliers de GeoNature ?