Pouvoir dupliquer le module occtax

DonovanMaillard commented 5 years ago

Je me pose la question de pouvoir dupliquer le module occtax, c'est-a-dire l'installer 2 fois, 3 fois sur une même instance?

Le module répond à la majorité des besoins pour un certain nombre de protocoles qui ne relèvent que des informations simples (chasses nocturnes, prélèvements adn etc).

L'installer plusieurs fois permettrait d'avoir des listes de taxons saisissables dans tel ou tel occtax, d'avoir les valeurs par défaut propre à chaque protocole simple, éventuellement donner l'accès à tel ou tel protocole selon les utilisateurs et leurs cruved.

Qu'en pensez vous? Est ce que cette possibilité servirait à d'autres personnes? :)

gildeluermoz commented 5 years ago

On en a déjà parlé et je pense que c'est une bonne idée mais il faut pour cela, au préalable, faire qq adapatations pour entre autre :

customiser le nom du module selon le sujet
permettre une installation d'un schéma dédié avec un nom évocateur du sujet
...??? Ceci demande des adaptations. Théo devrait savoir nous dire la compléxité de ces adapatations. Peut-être faut-il laisser occtax tel que et faire un module "adaptative_occtax" qui lui, serait customisable.

xavyeah39 commented 5 years ago

Salut Donovan, Je m'interroge aussi sur cette option et pour les mêmes besoins. Aussi pour permettre de configurer différemment le champ observateurs en texte libre ou en liste select selon l'utilisateur, son organisme, son cruved et selon si on gère où pas, le référentiel utilisateurs des organismes partenaires auxquels on ouvre son instance (actuellement soit l'un soit l'autre dans la conf occtax). Il me semble qu'avec l'architecture modulaire c'est tout à fait possible en faisant les adaptations nécessaires pour que les différents modules occtax n'aient pas les mêmes noms et identifiants. En tout cas oui ça m'intéresse, et volontaire pour tester. On se cale un workshop ? ;))

TheoLechemia commented 5 years ago

Ok pour avoir plusieurs "modules" occtax, mais à condition qu'ils écrivent tous dans le même schéma "pr_occtax". A priori ça ne devrait pas poser de problème. Il y a une modif à faire pour ne pas relancer le script SQL de création du schéma (https://github.com/PnX-SI/GeoNature/blob/master/contrib/occtax/install_gn_module.py#L15) et changer le code du module dans le fichier "manifest.toml" https://github.com/PnX-SI/GeoNature/blob/master/contrib/occtax/manifest.toml#L2. J'essaye de tester prochainement

TheoLechemia commented 5 years ago

A voir comment articuler ça avec la problématique des champs additionnels. (Il y a un ticket à ce propos que je ne retrouve pas)

DonovanMaillard commented 5 years ago

Ok pour avoir plusieurs "modules" occtax, mais à condition qu'ils écrivent tous dans le même schéma "pr_occtax".

A voir si c'est toujours compatible avec la gestion des valeurs par défaut notamment.

Les champs additionnels ont été évoqués hier coté module d'import, je ne sais pas si c'est à celui là que tu fais référence :)

camillemonchicourt commented 5 years ago

Si le modèle de données cible est similaire, je pense au contraire qu'il faut éviter cette piste au maximum. Ça va dupliquer beaucoup de choses difficiles à maintenir.

Il faut plutôt aller vers des possibilités d'avoir des listes de taxons différentes en fonction du JDD, des valeurs par défaut en fonction du JDD ou de l'organisme (prévu dans la BDD) etc.

Mais dupliquer le module serait vraiment dommage.

DonovanMaillard commented 5 years ago

Par organisme, ca ne repond pas à la problématique (et le plus souvent c'est un seul organisme qui va saisir dans son instance). Par jeu de données, ça peut devenir plus pertinent dans l'usage que j'imagine pour ma part, à voir pour les autres. Mais ça empêche quand même (a priori) de masquer/afficher tel ou tel champs selon les besoins.

TheoLechemia commented 5 years ago

Mais dupliquer le module serait vraiment dommage.

C'est pas dupliquer, on garde la même base de code, pas de problème de maintenabilité, on offre juste la possibilité de l'installer deux fois. Mais oui, la personnalisation par JDD est une piste aussi. Faut voir ce qui est le plus lisible

camillemonchicourt commented 5 years ago

En effet si ça écrit dans les mêmes tables alors c'est moins problématique.

DonovanMaillard commented 5 years ago

En fait ça répond même pas tant que ça. S'il faut définir une conf pour chaque jdd, si je prends mon exemple ou le cas d'un BE, il faudra faire une dizaine de conf , en gros une par étude/prestation réalisée.

gildeluermoz commented 5 years ago

Il serait utile de poser le sujet sur une feuille et de voir à quel niveau placer quoi en fonction de l'objectif + voir ce qui est déjà possible et ce qui demande des modifs.

Quel objectifs ? :

avoir un module dédié (masquable dans le menu)
travailler depuis un seul occtax et jouer sur les JJD
besoin de champ additionnels ou pas

Configurer quoi ?

les nomenclatures par défaut
d'autres valeurs par défaut que les nomenclatures (JDD, observateur, taxons, etc...)
les champs éditables

A quel niveau ?

module dédié (conf spécifique au module et à l'instance)
base de données (interface admin, conf souple mais complexité associée)
- JDD (filtrage selon utilisateur, organisme, module, nomenclature, taxon, ...)
- nomenclatures (liens avec organismes, utilisateurs, module, taxonomie, ...)
  - valeur par défaut
  - filtrage du contenu
fichier de conf (instance GN)
interface du module (conf utilisateur)

Pour qui ? (lien CRUVED)

utilisateur
organisme
instance

Ce travail permettrait de bien identifier de quoi on parle et d'envisager des évolutions de manière le plus générique possible.

camillemonchicourt commented 5 years ago

Oui clairement à sujet à poser dans sa globalité.

camillemonchicourt commented 5 years ago

Ce n'est qu'une réponse partielle, mais si il est trop lourd et trop fin de définir des choses au niveau des JDD, on peut imaginer pouvoir les définir au niveau des CA, qui regroupent plusieurs JDD

DonovanMaillard commented 5 years ago

Pour moi, JDD / CA même combat sur cette question là. 1CA=1 étude (=1 ou peu de JDD le plus souvent...) dans la logique des choses (puisqu'on y définit les financeurs etc). Ce choix là correspond bien pour des JDD ou des cadres qui durent sur le long termes, auprès des gestionnaires en effet, mais pas à toutes les catégories d'utilisateurs à mon avis.

Si c'est moins lourd comme ça en se basant sur les jdd, pourquoi pas envisager une conf dans le module admin par exemple pour limiter les inconvénients? Mais à l'usage (sans connaitre la lourdeur du truc en termes d'administration/développement), ca impose quand même de définir les choses régulièrement. Je verrais plutôt des modules occtax installés comme s'il s'agissait de plusieurs modules indépendants les uns des autres, avec chacun leurs listes, leurs id_modules, leurs cruveds donc, leurs valeurs par défaut, leurs champs masqués ou non dans l'interface, leur export....

Quant au fait de poser le sujet dans sa globalité, je pourrai apporter des réponses sur les besoins/objectifs/pour qui. Je laisse aux pros les aspects techniques :) Mais évidemment volontiers pour contribuer aux réflexions :)

gildeluermoz commented 5 years ago

Je vous propose une base de réflexion. Même s'il y a beaucoup de noir, ça ne fait pas le café... Ceci ne traite pas des permissions mais seulement du comportement de l'interface.

En vert : ce qui existe (au moins en base) mais qui n'est pas forcement implémenté en interface En bleu : ce qui reste à faire en rouge ce qui est discutable

Et biensur, tout est discutable. Le fichier est à votre disposition sur demande si vous souhaitez y travailler.

camillemonchicourt commented 5 years ago

Un peu hors-sujet, mais si on associe les acteurs aux JDD et aux CA et que cela pousse à quasiment faire 1 CA = 1 JDD, alors cela perd tout son sens. Je pense du coup qu'il faut choisir où on associe les acteurs, je dirai aux JDD et pas aux CA. Dans tous les cas, si on les associe aux 2, ça va être ingérable et inutilisable quand on exporte des données on prend quoi ? Et quand on applique le CRUVED etc...

DonovanMaillard commented 5 years ago

En effet, il serait plus judicieux d'avoir les acteurs au JDD, et que tous les acteurs des JDD soient associés au cadre qui les contient... mais le référentiel n'est pas conçu comme ça...

Pour Gil j'ai l'impression que si tout ce qui est en bleu est fait, on aura :

les nomenclatures du jdd
qui écrasent les nomenclatures du module
qui écrasent les nomenclatures de l'instance... 3 endroits pour paramétrer des nomenclatures qui se superposent ça me parait surprenant, même si en effet chacun peut ensuite paramétrer à l'échelle de son choix... mais dans ce cas, pourquoi ne pas centraliser les choses? Dans tous les cas, on m'a refusé un champ en plus dans le ref_geo (ça va camille, je plaisante!), et là on a plusieurs tables qui s'écrasent les unes les autres ... à voir

gildeluermoz commented 5 years ago

Chacun est libre de construire ses JJD et CA comme il l'entend. Mais il est évident que la logique producteur n'est pas la même que la logique intégrateur (SINP). Le modèle du standart SINP concernant les métadonnées, traduit dans le modèle GN2, prévoit de rattacher les acteurs aux CA et aux JDD. Pour répondre à l'intérrogation de Camille, je pense que l'entrée principale doit rester le JDD. Les CA ne sont que des boites de regroupement. Si on pousse la réflexion, le modèle SINP est problématique car pouvant générer les incohérences qu'aborde Camille. Par ex : si tu as x JJD dans un CA et que tous les acteurs des JDD ne sont pas "répétés" dans les acteurs du CA, ou inversement que certains acteurs ne sont décrits qu'au niveau CA = incohérence. En toute logique, on ne devrait décrire les acteurs qu'au niveau JDD et les acteurs du CA sont la sommes des acteurs des JDD. De ce fait, je pense qu'il faut rester sur l'usage actuel en interface (CRUVED, filtrage, etc...) uniquement sur les JDD.

DonovanMaillard commented 5 years ago

D'accord sur ce point Gil. Je crois (à confirmer, je sais plus d'où je tiens ça) que l'argument est de dire qu'un financeur peut financer un cadre sans viser un jdd en particulier... mais oui, ça serait plus simple pour tout le monde de fonctionner comme tu le décris. Et oui, garder le CRUVED etc sur les jdd est plus intéressant à priori...

gildeluermoz commented 5 years ago

Donovan, La logique est la même que pour le CRUVED, si tu ne fais pas de conf spécifique pour un module, c'est celle de l'instance qui s'applique. Mais oui, c'est complexe et c'est bien pour ça qu'il faut se poser pour y réfléchir.

camillemonchicourt commented 5 years ago

De toute façon, je vois pas comment on peut laisser associer des acteurs aux JDD et aux CA. Ça va créer des conflits, des incohérences et lequel on prend quand on veut exporter les données ou appliquer le CRUVED. Il faut surement ouvrir un autre ticket sur le sujet, mais pour être clair, il faudrait faire un choix et l'appliquer aussi au niveau de la BDD. Peut-être en n'ayant plus d'association d'acteurs au niveau des CA.

DonovanMaillard commented 5 years ago

Je suis de ton avis là dessus (on en avait déjà parlé je crois), avoir les acteurs au niveau du cadre ne me semble pas indispensable non plus, autant que ca soit l'ensemble des acteurs de ses jeux.

TheoLechemia commented 5 years ago

Première investigation pour installer deux fois le module Occtax. C'est donc techniquement bien possible, je viens de le tester. Il suffit de sortir occtax du dossier contrib pour le mettre n'importe ou sur sa machine et de changer le "module_code" du fichier '"manifest.toml". J'ai également rajouté un paramètre à la commande "install_gn_module" pour ne pas activer le backend (celui doit être installé qu'une seul fois). En fait on installe deux fois le front qui fait appel à la même API qui lit/ecrit dans la MEME base.

Les limites actuelles:

l'interface carte/liste est la même pour les deux modules, donc on a deux fois les même données
les triggers vers la synthese se serve du "code module" pour trouver l'id_source et l'id_module. Le code module est marqué en dur dans les triggers en SQL, donc pas possibilité de passer un paramètre.
Les nomenclatures par défaut sont gerées en base (pr_occtax.defaults_nomenclatures_value) et n'integre pas de notion de module

Il existe des solutions pour palier à ça. Reste à savoir si on veux bien faire d'Occtax un "meta-module" duplicable en fonctions des besoins.

TheoLechemia commented 2 years ago

Je déterre ce ticket. On a bien avancé depuis, notamment avec les champs additionnels et le besoin d'isoler le module Occtax "simple" du module Occtax avec certains champs additionnels se faisait ressentir. C'est donc désormais possible de simuler une duplication d'occtax pour un JDD sur lequel on a des champs additionnels. Cela crée un nouvel item dans la liste des modules, fournie une interface map/list préfiltré avec le JDD qu'on a passé en paramètre, et affiche les champs additionnels du JDD directement. Reste plus qu'a proposer des nomenclature par défaut qui s'adapte au JDD ? Voir la doc : https://github.com/PnX-SI/GeoNature/commit/43fa6c116a47ae3bb3bd601874b85d36071da969

DonovanMaillard commented 2 years ago

Est-ce que quelque chose est prévu/planifié pour les nomenclatures à ce stade, ou est-ce que ca reste à projet à réfléchir ?

Dans l'idée ca reste quand même une approche différente de ce qui avait été proposé, si j'ai 10 études papillons de jour et 10 etudes papillons de nuit, je ne peux pas faire un module nuit un module jour, puisqu'ils ont chacun 10 datasets. Mais on ne peut pas chercher à répondre à tout et à tout le monde avec un seul module c'est évident :) L'approche ici colle bien mieux à la logique 1 protocole = 1 dataset = 1 format de données => 1 formulaire de saisie

camillemonchicourt commented 2 years ago

Rien ne t'empêche d'associer les mêmes champs additionnels à plusieurs JDD

camillemonchicourt commented 1 year ago

Intégré dans la 2.0.0.

On ne duplique rien niveau BDD, on ajoute un item dans la barre latérale des menus et on limite le "module" Occtax dupliqué à un JDD avec ses champs additionnels.

Voir doc https://github.com/PnX-SI/GeoNature/pull/2120/files

A noter aussi :

Possibilité d'ajouter des droits spécifiques à ce module (le module code 'OCCTAX' n'est pas en dur mais passé en paramètre
La liste des données est filtrée uniquement avec les JDD associés au module
Cela a nécessite aussi de mettre en place le routage dynamique et l'ajout de la colonne ng_module dans la table gn_commons.t_modules. Le fichier de routing des modules est désormais autogénéré à partir de la table t_modules.

A voir par ailleurs si il faut faire des évolutions pour :

Pouvoir associer plusieurs JDD à un Occtax dupliqué
Pouvoir associer des valeurs par défaut pour un Occtax dupliqué

camillemonchicourt commented 1 year ago

Documentation intégrée : https://docs.geonature.fr/admin-manual.html#dupliquer-le-module-occtax

Au PNE, cela nous permet de proposer directement dans le menu latéral, un module "Flore station" associée à seulement un JDD, une liste de taxon spécifique et tous les champs additionnels pour ce protocole :

gildeluermoz commented 1 year ago

:+1: Beau travail les gars. Une petite pensée pour Cédric !

PnX-SI / GeoNature

Pouvoir dupliquer le module occtax #621