search

PnX-SI / gn_module_validation

Module de validation de GeoNature
3 stars 0 forks source link

Définition générale du module #4

Open camillemonchicourt opened 6 years ago

camillemonchicourt commented 6 years ago

CCTP : http://geonature.fr/documents/cctp/2017-12-CCTP-Module-Validation-GeoNature.pdf

Le module a été discuté globalement ici : https://github.com/PnX-SI/GeoNature/issues/181

vpilorge commented 6 years ago

Liens vers les maquettes réalisées pour le module validation:

https://projects.invisionapp.com/boards/GB3KE818KNP/ https://projects.invisionapp.com/boards/UA3KE81Z5XT/ https://projects.invisionapp.com/boards/PB3KE817NTK/

Dans l'attente de vos retours/avis/questions (possible directement sur inVision).

Cdt,

camillemonchicourt commented 6 years ago

Le CR de la première réunion sur le module : CR-PNR-08032018.pdf

Il y a différents points à discuter/compléter.

camillemonchicourt commented 6 years ago

Voici mes remarques sur ce CR, sur la base de ce qui avait déjà été discuté (https://github.com/PnX-SI/GeoNature/issues/181#issuecomment-358240295)

On ne valide que sur OccTax pour l’instant

Pour être générique et ne pas avoir un module de validation par protocole de GeoNature, on avait validé le fait de valider dans la Synthèse. Cela permet aussi de valider n'importe quel données, venant de n'importe qu'elle source. Se pose cependant la question de savoir si une validation d'une observation dans la Synthèse, vient modifier la statut de validation de la donnée source (cela créerait des flux bidirectionnelles par forcément souhaités) ou si quand on ne stocke aucune info de validation dans la donnée source et quand on veut connaitre son statut de validation, on fait une jointure entre la donnée source et la donnée synthèse.

#########

Afficher, ou du moins pouvoir accéder, à tous les champs présents dans la synthèse. Les champs affichés actuellement ne suffisent pas à pouvoir valider les données. La liste peut afficher quelques champs, mais il faut pouvoir afficher le détail d'une observation. Il doit aussi falloir pouvoir accéder à une donnée source, qui est potentiellement plus précise que celle présente dans la Synthèse. Un mécanisme similaire de remontée à la donnée source est en cours de développement dans le module Synthèse. Enfin il faut pouvoir filtrer sur beaucoup plus de champs. Tous ceux de la Synthèse au final. Comme on a actuellement dans Occtax, on peut envisager, d'afficher en permanence les filtres principaux mais de pouvoir accéder à tous les autres filtres si besoin. Le filtre Famille par contre n'était pas prévu. Pourquoi ce rang et pas les autres ? Si on peut filtrer par rang, prévoir un système plus générique multi-rang avec un arbre qui permet de choisir n'importe quel rang. Cette fonctionnalité sera aussi implémenter dans la Synthèse.

#########

Un validateur doit pouvoir être associé à un ou plusieurs groupes

Je comprends bien ça, mais ça n'a pas été prévu par le mécanisme générique du CRUVED. Pour chaque utilisateur ou groupe d'utilisateur, celui-ci permet de définir des actions possibles (CRUVED), sur une portée (Mes données, Les données de mon organisme, Toutes les données) dans un module donné. Si on a une notion de groupes pour la validation uniquement, alors on complexifie et on casse la généricité du mécanisme. A bien discuter/évaluer.

#########

#########

Une reflexion est en cours sur l'historisation des validations et plus largement sur l'historisation des actions sur un objet. https://github.com/PnX-SI/GeoNature/issues/339

#########

Au final, il y a beaucoup de similitudes et de fonctionnalités communes avec la Synthèse. Plus de 80% du module est similaire. A bien articuler, mettre en cohérence et factoriser, le module Synthèse étant en cours de développement.

#########

Un des aspects les plus intéressants de ce module, est la mise en place de règles dans la BDD permettant de détecter et mettre en avant les données exceptionnelles. Ces règles peuvent s'appuyer sur les observations existantes dans la BDD (taxon jamais vu à cette altitude, ou à cette période, dans cette commune, croisement avec milieux etc...) ou sur des attributs globaux associés au niveau des taxons dans TaxHub (phénologie notamment). Il est dommage de mettre de côté cette réflexion.

camillemonchicourt commented 6 years ago

Concernant le fait de valider en Synthèse, il y a 3 approches possibles :

Le cas 2 est le moins souhaité car il génère des flux bi-directionnel entre Synthèse et Données sources. Le cas 1 n'est pas très souhaitable non plus car il amène à avoir des données dans la Synthèse qui ne sont pas dans les données sources. Le cas 3 semble le plus sain, mais il nécessite d'avoir un mécanisme reporté dans tous les schémas sources. Et quid si on a des données dans la Synthèse qui n'ont pas de données sources ?

PS : Si on valide au niveau de la synthèse, une ligne = une occurrence de taxon = un dénombrement. Donc si on a un relevé, avec 3 taxons qui ont 2 dénombrements chacun, cela fait 6 occurrences de taxons, donc 6 lignes à valider.

camillemonchicourt commented 6 years ago

Témoignage de @jbrieuclp :

Précédemment j'avais mis en place un système de validation permettant de valider les taxons de façon groupés :

Et pour compléter, tu peux ensuite dérouler les dénombrements d'une observation (nom cité) pour valider spécifiquement chacune de ces valeurs.

gildeluermoz commented 6 years ago

@Camille L'option 2 casse le principe de modularité. Le core (synthèse) ne peut pas être dépendant de l'existence d'un module en écrivant dedans. Donc non. L'option 3 est la meilleure. Pour les données présentes uniquement en synthése, 1- soit elles ne sont pas validables (ne remontent pas dans le module de validation) et c'est à l'administrateur bdd qui les a insérées de gérer le statut de validation. 2- soit vu qu'elles n'ont pas de source interne (id_source ou id_parent = nulle ou = 0), le module de validation valide dans la synthèse au lieu de valider la source. La 1 me semble plus propre. Mais la 2 reste possible si on considère alors la synthèse comme une source valide : on peut avoir un mécanisme générique qui identifie l'enregistrement (shema.table.field + pk value). L'insertion de données directement en synthèse doit alors se faire en indiquant 'gn_synthese.synthese.id_synthese' dans entity_name. Il serait alors préférable que le champ portant l'id_nomenclature de la validation ait tjs le même nom.

camillemonchicourt commented 6 years ago

Oui on est d'accord. L'option 3 est la moins pire.

camillemonchicourt commented 6 years ago

Concernant les données qui ne sont pas dans la Synthèse, je pense qu'on ne devrait même pas pouvoir les valider. Vu que ce sont des données de synthèse, elles ne devraient avoir aucune info spécifique. La synthèse ne devrait être que le synthèse d'autres données. Donc ne contenir aucune info non présentes ailleurs.

gildeluermoz commented 6 years ago

On est d'accord. C'est ma proposition 1 que je trouve plus propre précisément pour les raisons que tu exposes. Cela respecte le principe défini dès le début du projet : on écrit pas dans la synthèse (depuis l'application) qui est en lecture seulement.

Il faut cependant savoir qu'un admin peut le faire. Dans ce cas soit on défini ça comme une mauvaise pratique en interdisant la validation sur les données ainsi insérées et donc isolées. Ce qui peut le forcer à reprendre de bonnes pratiques. Soit on le permet (ma proposition 2) en considérant que c'est le pb de celui qui le fait ou qu'il a potentiellement une bonne raison de le faire.

Au delà du principe, à voir s'il y a de potentiels effets de bord à valider des données isolées en synthèse. Dit autrement quelle serait la vraie bonne raison de ne pas pouvoir le faire.

orovellotti commented 6 years ago

Donc on part sur l'option 3 : "On se base sur la Synthèse pour lister les données, mais quand on réalise une action de validation, l'enregistrement en BDD se fait au niveau de la donnée source et non pas au niveau de la Synthèse. La modification est répercutée dans la Synthèse par le trigger Source >> Synthèse. Inconvénient : Là aussi ça nécessite d'avoir un mécanisme générique et similaire dans tous les protocoles sources."

Est ce que Sylvain est sur Github, ou faut il valider ca avec lui part email?

camillemonchicourt commented 6 years ago

Oui on reboucle un coup entre nous sur le sujet et on confirme. Sylvain est sur Github et reçoit ces discussions : https://github.com/PnX-SI/gn_module_validation/watchers

camillemonchicourt commented 6 years ago

4° solution proposée par @amandine-sahl et qui règle les différents inconvénients évoqués dans les 3 premières propositions : On centralise la validation comme les médias. Comme ça c'est standardisé et centralisé mais pas dans la Synthèse. Et on n'a pas besoin de répercuter un mécanisme commun de validation dans chaque protocole, schéma source.

Un schéma gn_validation dans lequel on a une table centralisant les validations de tous les objets avec :

Voir le schéma de gestion des tables de stockage transversal : https://github.com/PnX-SI/GeoNature/issues/339#issuecomment-375716476

A noter aussi que l'historisation des actions sur une donnée gérée de manière globale permettra de gérer l'historique de validation d'une donnée.

camillemonchicourt commented 6 years ago

Malgré tout, les inconvénients de la solution 4 sont :

On en discute dans le point globale du début de sprint Avril.

sig-pnrnm commented 6 years ago

(désolé pour mon absence prolongée, mais je suis en arrêt et un peu loin les échanges)

De mon côté, je suis à 100% favorable à l'option 4 proposée par @amandine-sahl (que j'avais plus ou moins en tête depuis le début, mais que je n'aurais pas su formaliser si bien).

Parmi les problèmes de cette solution que tu soulèves Camille, je ne comprend pas en quoi cela manque d'intégrité : l'ID permanent SINP (https://github.com/PnX-SI/GeoNature/issues/209) ne pourrait-il pas servir de clé étrangère ?

TheoLechemia commented 6 years ago

En fait la clé étrangère doit référencer un champ spécifique d'un table spécifique. Donc ça ne marche pas si les donnés proviennent de plusieurs tables de plusieurs protocoles.

DonovanMaillard commented 6 years ago

Instinctivement, j'aurais plutôt imaginé l'option 3, où la synthèse centralise les données avant de les "renvoyer" vers le module de validation, mais où c'est bien la table mère qui enregistrait l'info de la validité (avant, donc, de revenir dans la synthèse par le trigger classique).

Sur la 4 si j'ai bien compris, ça complique les exports, les updates etc puisque toutes les infos de la validation sont "détachées" des tables mère et synthèse ? Et derrière, les vues des atlas, qui devront aussi reprendre cette notion de validité? Ainsi que le projet de table d'archivage, qui devra aussi aller chercher ses infos au niveau du schéma validation?

J'aurais plutôt vu la validation comme une sorte "d'update" de la donnée, donc dans son protocole mère si on suit la logique d'un update classique.

C'est sur que ça ferait un module à part entière qui peut être activé ou non sans trop toucher au reste, mais... finalement ça semble complexifier un certain nombre d'autres projets, la validation étant mine de rien assez centrale.

vpilorge commented 6 years ago

Avez-vous eu l'occasion de boucler sur le sujet et décider si l'on opte pour la solution 3 ou bien pour la solution 4 ?

camillemonchicourt commented 6 years ago

On doit en parler demain ou lundi.

camillemonchicourt commented 6 years ago
vpilorge commented 6 years ago

Voici les maquettes retouchées pour ce module en prenant en compte vos précédentes critiques :

https://projects.invisionapp.com/boards/BD3KE81G4N2/ https://projects.invisionapp.com/boards/7H3KE812DRB/ https://projects.invisionapp.com/boards/MU3KE81QA8V/ https://projects.invisionapp.com/boards/5Q3KE81BKY3/ https://projects.invisionapp.com/boards/5Q3KE81BKY3/

Je reste à votre disposition si vous avez des interrogations.

Dans l'attente de vos retours.

camillemonchicourt commented 6 years ago

OK on part sur la solution 4 après les tests de performance et la discussion globale https://github.com/PnX-SI/GeoNature/issues/339

On valide dans gn_commons.validation, par contre on duplique l'info en trigger dans la Synthèse pour avoir les infos à plat mais aussi pour pouvoir stocker uniquement dans la Synthèse, le statut de validation de données externes intégrées (sans nécessité de les gérer dans des tables tierces).

Il est aussi possible de tracer les historiques du statut de validation d'un objet.

camillemonchicourt commented 6 years ago

OK, pour les maquettes, ça me semble coller. Il y aura des petits ajustements à faire sur les filtres mais on en recausera. Par exemple plutôt que de filtrer sur une date, on voudra plutôt filtrer entre 2 dates, je ne sais pas si on fait des recherches sur cd_nom, cd_ref mais pourquoi pas.

Il y a tous les filtres liés aux nomenclatures. Pour celles-ci, @TheoLechemia a mis en place un composant générique (DynamicForm) qui permet de lister dans un fichier de conf les champs que l'on souhaite utiliser ainsi que leur type (https://github.com/PnX-SI/GeoNature/blob/develop/contrib/occtax/frontend/app/occtax-map-list/filters-list.ts) et ça les propose dynamiquement dans l'interface.

Pour ne pas surcharger l'interface en les affichant tous, ils sont affichés dans une liste déroulante : filtres

A tester dans le module OccTax dispo en demo sur http://demo.geonature.fr/geonature

Il y a 2 fois le lien d'une même maquette. Et on voit pas ce qu'il se passe quand on clique sur le plus d'une observation.

Et à articuler et factoriser avec pas mal de choses du module Synthèse (https://github.com/PnX-SI/GeoNature/issues/345)

vpilorge commented 6 years ago

Ok c'est noté pour la solution #4.

Niveau maquette je regarderai DynamicForm merci.

Mauvais lien pour le dernier, c'est une erreur de ma part. Voici ce qui se passe quand on clique sur le "+" : https://projects.invisionapp.com/boards/HY3KE815FQE/

camillemonchicourt commented 6 years ago

OK merci pour ces éléments. Pour le détail d'une observation, quand on les affichera, les infos ne sont pas modifiables car on affiches les infos de la Synthèse. On ne modifie aucune donnée de la Synthèse qui sont pilotées par le données dans le schéma Source. Il y aura par contre un lien pour revenir à la donnée et son édition dans le procotole Source (occtax ou autre). Le détail devra aussi pouvoir afficher l'éventuelle photo de l'observation (idéalement aussi indiqué dans la liste).

A noter aussi que, comme dans le module Synthèse, il y a une reflexion à avoir sur la pagination : https://github.com/PnX-SI/GeoNature/issues/357

gildeluermoz commented 6 years ago

Concernant cette dernière slide, si on peut afficher les commentaires et les dates des validations successives, il faut aussi afficher sur ces lignes vertes les états de validation correspondants.

vpilorge commented 6 years ago

Ok, c'est noté.

Merci pour vos retours rapides.

gildeluermoz commented 6 years ago

Concernant le choix des enregistrements à cocher pour leur attribuer un statut de validation, il me semble qu'il serait préférable d'avoir un scroll ; en tout cas pouvoir afficher beaucoup plus que 5 enregistrements. Ceci afin d'avoir une validation par lot présentant une vision d'ensemble plus évidente.

camillemonchicourt commented 6 years ago

Oui il faut pouvoir valider d'un coup tout un gros ensemble de données correspondant à une recherche et pas seulement les quelques données affichées sur la pagination active.

Un bouton TOUT COCHER qui cocherait pour tous les résultats de toutes les pages de résultat de la recherche ?

gildeluermoz commented 6 years ago

Tout cocher, y compris ce qui ne serait pas afficher c'est risqué. Donc non. Tout cocher ne devrait cocher que ce qui est visible sur la page.

camillemonchicourt commented 6 years ago

OK donc pas de pagination dans ce cas, sinon 20 par 20, ça va être infernal.

camillemonchicourt commented 6 years ago

La modélisation avance dans le stockage vertical centralisé de GeoNature et avec un mécanisme de valeur par défaut lors de l'insertion d'une donnée dans un protocole :

camillemonchicourt commented 6 years ago

La table de stockage des validations était déjà en place mais le trigger qui permet de disposer à plat de la dernière validation directement dans la Synthèse vient d'être ajouté : https://github.com/PnX-SI/GeoNature/commit/33c2097b691d2866313c5906f8591df36a2c913f

sig-pnrnm commented 6 years ago

Lien avec cette discussion : https://github.com/PnX-SI/GeoNature/issues/514

camillemonchicourt commented 5 years ago

CR de la réunion de mercredi 21 novembre 2018

Statuts

Code Couleurs

Validation Manuelle ou Automatique (En se basant sur le SINP)

SELECTION

Vue Détails

Interaction Carte-Liste

Filtre

Droit de validation dans GeoNature

Retour vers l’observateur

Jeux de données

Point abandonnés pour l'instant pour le cahier des charges :

RESTE A FAIRE :