nomenclatures par defaut

joelclems commented 3 years ago

Les changements récents liées à la release 2.8.0 ont mis à jour quelques soucis liés aux nomenclature par défaut. Principalement dus à l'utilisation d'id en dur dans le code (sql, backend, ..)

Il apparaît aussi que les tables defaut_nomenclature_value et les fonctions get_defaut_nomenclature_value sont définis plusieurs fois dans les schémas :

ref_nomenclatures
- utilisé pour les métadonnées
- ce qui crée une dépendance de la branche alembic nomenclature au schema utilisateur dans
- 'fa35dfe5ff27', # schéma utilisateurs, vers lequel le ref_nomenclatures a quelques FK
synthese,
pr_occtax,
pr_occhab

Cela correspond à des contextes et des utilisations différentes, mais n'est pas forcement simple à maintenir. Est t'il possible de centraliser des tables et les fonctions associées?

Proposition

Le nomenclatures par défaut sont des données/fonctionalités de géonature qui utilisent la nomenclature. Leur place n'est pas forcement dans le schema ref_nomenclatures, cela évite de créer une dépendance de ce dernier avec d'autres éléments, comme le schema utilisateurs.

Une api /gn_commons/defaultNomenclatures permettrais d'accéder à ces données.

L'idée proposée dans ce ticket serait de créer une seule table et une seule fonctions dans le schema gn_commons qui permettrait de centraliser la gestion des nomenclature par défaut.

La table `gn_commons.default_nomenclatures_values`

Il faut veiller à ce que cette table soit en concordance avec ce qui exise déjà:

il faudrait reprendre les champs existants
- mnemonique_type (ou id_type -> moins lisible mais mieux d'un point de vue sql et contraintes d'intégrité)
- id_nomenclature
- id_organisme
- regne (synthese)
- group2_inpn (synthese)
il faut pouvoir définir des contextes différents, on peut ajouter pour cela les champs :
- id_module
- id_dataset
les champs obligatoires (NOT NULL) seraient :
- mnemonique_type (ou id_type)
- id_nomenclature
- id_module ?
- on peut se poser la question de rendre id_module obligatoire car les nomenclature par défaut sont le plus souvent liées à un module
- une nomenclature par défaut pour tout geonature à t'elle du sens ou faut il au moins préciser le contexte du module
- cela donne plus de lisibilité à la table

le principe

dans une ligne de la table gn_commons.default_nomenclatures_values:
- si un champs de à pour valeur null par exemple id_organism cela veut dire que la ligne est valable pour tous les organismes
- exemples (les champs non spécifiés sont à null):
  - {mnemonique_type: 'METH_OBS', id_nomenclature: 323}
  - nomenclature par défaut pour le type METH_OBS de la façon la plus générale
  - {mnemonique_type: 'METH_OBS', id_nomenclature: 324, id_module : 4}
  - nomenclature par défaut pour le type METH_OBS et le module 4 (par exemple occtax)
  - {mnemonique_type: 'METH_OBS', id_nomenclature: 325, id_module : 4, id_organisme: 4}
  - nomenclature par défaut pour le type METH_OBS, le module 4 et l'organisme 4

La fonction `gn_commons.get_default_nomenclatures_value`

en entrées: mnemonique_type, ?id_module, ?id_dataset, ?id_organisme, ?regne, '?group2_inpn'
en sortie : id_nomenclature :
- renvoie la nomenclature par défaut pour les entrées demandées,
- renvoie NULL si rien n'est défini pour
- exemple :
  - on demande une nomenclature par défaut pour METH_OBS pour le module occtax et l'organisme 4
  - on trouve la ligne qui correspond et on obtient 325
  - on demande une nomenclature par défaut pour METH_OBS pour le module occtax et l'organisme 5
  - on ne trouve pas la ligne correspondante
  - on cherche avec moins de spécificité et on trouve la ligne
    - {mnemonique_type: 'METH_OBS', id_nomenclature: 324, id_module : 4}
  - on obtient 324
  - dans les cas ou on ne trouve rien on renvoie NULL
comment faire une méthode robuste et rapide pour aller chercher les valeurs par défaut

difficulté

par exemple on souhaite avoir une nomenclature par défaut dans occtax pour METH_OBS et la demande se fait pour un organisme et un jeux de données, on trouve deux ligne correspondante:

{mnemonique_type: 'METH_OBS', id_nomenclature: 326, id_module : 4, id_organisme: 4}
{mnemonique_type: 'METH_OBS', id_nomenclature: 327, id_module : 4, id_dataset: 17}

comment choisir la ligne à utiliser ?
faut il priorisé l'organisme ou le jdd
- mon avis est que le jdd est plus spécifique que l'organisme
comment hierarchiser les variable
- par exemple du moins spécifique au plus spécifique
- id_module < id_organisme < id_dataset (ou placer regne et goup2inpn)?
  Les avantages
une grande modularité d'utilisation
- pour un module on n'a plus qu'a remplir la table et utiliser la bonne api
une seule table de nomenclature par défaut et une seule fonction à maintenir
en terme de branche alembic : plus de dépendance de la nomenclature à usershub (pour ceux qui voudrait utiliser pypnomenclature indépendamment de geonature
plus de dépendance à la ligne de utilisateur.bib_organismes ALL
- on peut utiliser la valeur null

Les inconvénients

une table et une fonction pour récupérer les valeurs par défaut plus complexes
il faut trouver un moyen efficace de faire des recherches dans cette tables
des changements en profondeur dans le code
- à tous les niveaux
- SQL
- backend : modèles, routes
- et dans les différents éléments et modules
- geonature
- pypnnomenclature
- occtax
- autres...
un travail conséquent de mise à jour sql (désormais facilité par alembic)

DonovanMaillard commented 3 years ago

Même en termes de configuration, ca pourrait aider à y voir plus clair : pas toujours simple de savoir quelle conf surcouche la quelle. Mais ce que tu mentionnes soulève aussi plusieurs questions :

Faut-il réellement pouvoir configurer des nomenclatures pour un jeu de données en particulier : les JDD sont des données qui sont censées être dynamiques, et pour lesquelles il n'est pas forcément souhaitable de tout configurer. Par exemple chez nous un JDD=une étude, on en fait 10 à 15 par an, et ils vivent en moyenne 2 ans avant d'être inactivés. Conserver des configurations pour les JDD inactifs, configurer les listes de taxons, les modules, les nomenclatures etc pour chaque JDD soulève des questions...
Y a-t-il réellement des cas d'utilisations de la notion d'organismes dans les nomenclatures ? De mon coté, je gère une instance qui sert effectivement à plusieurs organismes, je ne sais pas si je ne suis pas le seul (??). Dans tous les cas, une instance à plusieurs organismes soulève d'autres soucis. Si en plus on souhaite à temres qu'un utilisateur puisse être associé à plusieurs organismes, ça posera de nouvelles questions... Est-ce que revoir ces configurations des nomenclatures ne serait pas une occasion de simplifier les choses, en refaisant le point sur ce qui est réellement utilisé ou non ? C'est d'autant plus vrai si on peut faire ces configurations au niveau du ou des JDD associés à un organisme donné... (à priori c'est plus sur les organismes que j'aurais tendance à supprimer cette possibilité au premier abord).

D'une manière générale, on commence a avoir énormément de choses qui se configurent au niveau du module, au niveau de l'organisme, au niveau du JDD... permissif mais plus complexe à configurer, maintenir, tester etc.

camillemonchicourt commented 3 years ago

Pouvoir définir des valeurs par défaut par organisme était une idée initiale qui a été prévue mais jamais utilisée.

A mon avis c'est trop complexe et pas forcément pertinent.

Je serait favorable à complètement enlever cette possibilité si il est confirmé qu'elle est utilisée par personne.

Si on doit pouvoir affiner les valeurs par défaut en fonction des contextes, alors ça aurait plus de sens au niveau des JDD.

Mais là aussi comme souligne Donovan, c'est complexe et je ne suis pas convaincu qu'il faille aller à ce niveau de finesse.

Dans tous les cas ça serait à implémenter plus tard si besoin et avec un usage bien clair.

Donc je serai pour simplifier et alléger cela.

Je supprimerai le champs "organisme" et je mettrai pas de champs "dataset" pour le moment sans usage identifié.

Je pense aussi que c'est galère et peu lisible d'avoir plusieurs tables similaires à différents endroits, et favorable à une seule table dans gn_commons.

Je me demande même si c'est réellement utile et utilisé de pouvoir définir ces valeurs par défaut par module ?

joelclems commented 3 years ago

je ne sais pas quelle est l'usage réel qui est fait dans la synthese des champs regne et group2inpn pour les nomeclature par defaut

une installation fraiche donne des lignes avec regne et group2_inpn qui ont toujours la valeur 0

camillemonchicourt commented 3 years ago

A voir si ça aussi c'est vraiment utile et utilisé ?

Autre tickets sur le sujet : https://github.com/PnX-SI/GeoNature/issues/553

DonovanMaillard commented 3 years ago

S'il y a une conf par JDD, je pense également que la conf par module peut disparaitre... dans tous les cas, les JDD sont suffisamment permissifs pour répondre à un maximum de besoins.

On peut avoir un jdd différent selon le module utilisé (en théorie c'est plus ou moins, un protocole = un module = un jdd dans les cas classiques?), selon les organismes, voire selon les groupes taxonomiques. Si on peut configurer par jdd, ça me semblerait plus simple et clair que les configurations ne se fasse QUE par jdd.

Un peu plus pénible sur le point cité plus haut, au niveau de la "persistence" des config puisque les jdd restent vivants et ont des fois une durée de vie assez courte. Mais on peut imaginer une configuration "par défaut" pour l'instance, qui est récupérée quand rien n'est défini au niveau du JDD. Ca permet de supprimer les notions d'organismes, de modules, et de groups taxo (j'ai 4 instances en prod, pas toutes configurées par moi à l'origine, aucune ne définit de nomenclatures en fonction du taxon...)

camillemonchicourt commented 3 years ago

https://github.com/PnX-SI/GeoNature/issues/1353

camillemonchicourt commented 3 years ago

https://github.com/PnX-SI/GeoNature/issues/280

camillemonchicourt commented 3 years ago

https://github.com/PnX-SI/GeoNature/issues/821

PnX-SI / GeoNature