Modification de données source > nouveau statut de validation automatique

[sig-pnrnm]

Toute modification de données source doit entrainer un nouveau statut de validation automatique "en attente de validation"
Attention : cela n'efface pas les éventuels statuts de validation précédemment attribués

(pour rappel, il avait été convenu qu'il n'était pas possible de distinguer quels types de modification entrainaient la modification du statut de validation)

[gildeluermoz]

j'attire votre attention sur le fait que toute modification, même mineure, va faire "perdre" le statut de validation.
Il serait souhaitable que ce comportement soit paramétrable (désactivable).
Si c'est un trigger qui doit faire ça, il faudrait à minima exclure certains champs entraînant la réinitialisation du statut de validation.

[sig-pnrnm]

va faire "perdre" le statut de validation.

Pas tout à fait car l'historique est conservé.

Si c'est un trigger qui doit faire ça, il faudrait à minima exclure certains champs entraînant la réinitialisation du statut de validation.

Pourquoi pas, si c'est possible.
Mais si personne n'a le temps de proposer cette liste de champs n'entrainant pas de modification, nous préférons que cette modification soit automatique, quelque soit le(s) champ(s) modifié(s)

[camillemonchicourt]

Ce sujet concerne au final peu le module de VALIDATION, mais plutôt les choix faits au niveau du module de données source.

J'avais compris que ce sujet n'était pas clair ni tranché : PnX-SI/GeoNature#514

Actuellement quand une occurrence est insérée dans Occtax, un trigger y applique la valeur par défaut définie dans la BDD : https://github.com/PnX-SI/GeoNature/blob/master/contrib/occtax/data/occtax.sql#L916-L920

Si on veut que chaque modification d'une occurrence, in-valide cette occurrence, il faut ajouter un trigger ON UPDATE qui recréé une validation de l'occurrence en mettant le statut par défaut.

Et reporter ça aussi sur le trigger Occtax >> Synthèse.

D'ailleurs, il faudrait avoir le même fonctionnement dans chaque module qui produit des données sources.

Donc c'est dé-corrélé du module de Validation.

Et pour moi, le fait d'invalider une occurrence après chaque modification n'était pas tranché.

[gildeluermoz]

Et si tu fais UPDATE matablesource SET altitude_min = altitude_max WHERE id_role = 36;
ou UPDATE matablesource SET meta_v_taxref = 'V9' WHERE id_role = 36;

ou tout autre requêtes admin (calcul d'intersect avec l'altitude, la commune ) etc...
Tu modifies 5000 lignes et tu dois refaire ou récupérer tous tes statuts de validation... Si tu y as pensé !
Vous assumez ça ?

Autre point, il faudra exclure des champs du trigger car lors de la MAJ de validation_comment, c'est un update de l'enregistrement, donc déclenchement du trigger, donc réinitialisation du statut de validation.

[DonovanMaillard]

Mais si personne n'a le temps de proposer cette liste de champs n'entrainant pas de modification, nous préférons que cette modification soit automatique, quelque soit le(s) champ(s) modifié(s)

Si c'est la seule problématique, je n'ai aucun soucis à faire des propositions sur les champs qui doivent ou non remettre en cause une validation. En général, on se base sur un lieu, une période (nos dates ici), une méthode, et naturellement l'espèce. Ajouter un observateur, changer l'effectif ou préciser le sexe par exemple ne sont pas de nature à changer la validation dans la majorité des cas.

Camille, est-ce qu'on peut pas aussi ne pas taper dans tous les modules justement, et avoir un système qui se base sur les date update de la synthèse? Si date update plus récent que date validation, la vaidation revient en attente. Par contre en effet, ce mécanisme empêcherait un tri par champ.

Mais contraindre tous les modules pour la validation, c'est un peu dommage dans l'idée, non? Ou alors c'est qu'un trigger à ajouter à chacun des modules? Je me rends pas bien compte...

[camillemonchicourt]

@gildeluermoz , je pense aussi qu'invalider tout update est dangereux et non souhaitable.
Par contre, il n'y a plus de champs lié à la validation dans Occtax, validation_comment est dans la Synthèse et dans la table verticale.

@DonovanMaillard , c'est un choix à faire au niveau de chaque module avec un trigger.
Actuellement il n'y a qu'un trigger lors de la création d'une occurrence, qui créé une validation avec la valeur par défaut définie dans la BDD.

[gildeluermoz]

Ou alors c'est qu'un trigger à ajouter à chacun des modules?

Effectivement si c'est une fonction trigger qui fait ça et que tu veux que le trigger réagisse différemment selon le champ modifié, tu ne peux pas trop le faire générique.

Pour le reste, le sujet principal c'est qu'avec cette règle tu t'interdit, ou du moins tu alourdis, toute intervention en sql dans ta source

[gildeluermoz]

c'est un choix à faire au niveau de chaque module avec un trigger.

Effectivement. Du coup je ne suis pas pour le faire dans occtax. Si un admin pg veut l'ajouter, il l'assume.

[camillemonchicourt]

Oui

[sig-pnrnm]

J'entends vos remarques concernant des modifications faites en admin.
Et dans ce cas, je suis de votre avis : les modifications ne doivent pas entraîner de nouveau statut de validation.

PAR CONTRE
Dans le cas d'une donnée modifiée via un formulaire, par le "digitizer", là le statut doit être modifié.
Et du coup, ce n'est pas un trigger généralisé : il doit tenir compte que la modification a été faite dans un formulaire (OccTax ou autre)

[sig-pnrnm]

Ce genre de modification, par un utilisateur (digitizer) reste assez marginal, mais peut entrainer des gros biais si la validation n'est pas réinspectée. Imaginons un petit malin qui veut faire passer une donnée en squizzant le processus de validation : il saisit sa donnée d'espèce banale, attend la validation, puis modifie sur une espèce exceptionnelle...
Ok, c'est capillotracté : mais plus on va ouvrir la saisie GeoNature à un nombre croissant d'utilisateurs, plus on va avoir potentiellement de risque de tomber sur un "crétin" ;)

Si c'est la seule problématique, je n'ai aucun soucis à faire des propositions sur les champs qui doivent ou non remettre en cause une validation.

C'est l'idéal en effet.
Je veux bien participer : du coup, si je me base sur les champs de la synthèse, c'est bon ?

[camillemonchicourt]

Si on met ce genre de mécanisme en place, il faut le faire en trigger pour rester cohérent et ne pas avoir de choses exotiques qui se font au niveau de l'interface uniquement.

Je comprends l'idée d'invalider, pas celle de celui qui veut tordre le truc.

Comme dit Gil, une solution est que ceux qui veulent se mettent un trigger ON UPDATE sur le modèle de celui ON INSERT et ils peuvent le faire sur les champs qu'ils veulent.

[sig-pnrnm]

Comme dit Gil, une solution est que ceux qui veulent se mettent un trigger ON UPDATE sur le modèle de celui ON INSERT et ils peuvent le faire sur les champs qu'ils veulent.

OK, si c'est juste un trigger à écrire, je devrais pouvoir le faire sur mon instance.

Si jamais vous aviez un modèle, n'étant pas encore familier des Triggers, je suis prenneur.
D'ailleurs, plus généralement, ce sera utile, dans le cadre de ce module, de partager des exemples de requêtes SQL en Admin pour ajouter un statut de validation (histoire de ne pas oublier d'éventuels champs).

Voici la liste des champs de la synthèse avec une première ébauche pour identifier ceux qui pourraient nécessiter une revalidation :
(il y a beaucoup de "???" parceque je ne connais pas encore la définition de ces champs)

champ	type	revalidation
id_synthese	integer	non
unique_id_sinp	uuid	non
unique_id_sinp_grp	uuid	non
id_source	integer	non
id_module	integer	non
entity_source_pk_value	character varying	non
id_dataset	integer	non
id_nomenclature_geo_object_nature	integer	oui
id_nomenclature_grp_typ	integer	???
id_nomenclature_obs_meth	integer	???
id_nomenclature_obs_technique	integer	???
id_nomenclature_bio_status	integer	???
id_nomenclature_bio_condition	integer	???
id_nomenclature_naturalness	integer	???
id_nomenclature_exist_proof	integer	???
id_nomenclature_valid_status	integer	???
id_nomenclature_diffusion_level	integer	???
id_nomenclature_life_stage	integer	???
id_nomenclature_sex	integer	???
id_nomenclature_obj_count	integer	???
id_nomenclature_type_count	integer	???
id_nomenclature_sensitivity	integer	???
id_nomenclature_observation_status	integer	???
id_nomenclature_blurring	integer	???
id_nomenclature_source_status	integer	???
id_nomenclature_info_geo_type	integer	???
count_min	integer	oui
count_max	integer	oui
cd_nom	integer	oui
nom_cite	character varying(1000)	oui
meta_v_taxref	character varying(50)	???
sample_number_proof	text	???
digital_proof	text	oui
non_digital_proof	text	oui
altitude_min	integer	non
altitude_max	integer	non
the_geom_4326	geometry(Geometry,4326)	oui
the_geom_point	geometry(Point,4326)	oui
the_geom_local	geometry(Geometry,4326)	oui
date_min	timestamp without time zone	oui
date_max	timestamp without time zone	oui
validator	character varying(1000)	???
validation_comment	text	???
observers	character varying(1000)	oui
determiner	character varying(1000)	oui
id_digitiser	integer	non
id_nomenclature_determination_method	integer	oui
comments	text	oui
meta_validation_date	timestamp without time zone	???
meta_create_date	timestamp without time zone	???
meta_update_date	timestamp without time zone	???
last_action	character(1)	non

[gildeluermoz]

Je ne partage pas la proposition de Camille. Le trigger va générer les soucis que j'expose pour toute modif en sql.
Une invalidation pour des modifs via l'interface, comme le propose Sylvain me semble plus cohérente. Et comme chacun doit choisir son comportement, il faut que ce comportement soit activable/désactivable.

Pour les triggers regarde la base, dans le module occtax, tu as de quoi faire. Attention, ne modifie pas les trigger existant si tu ne maitrise pas. C'est sensible. On a galéré pour que tout roule sans bug.
Attention par contre si tu as 2 triggers update sur la même table, tu ne sais pas trop lequel est exécuté en premier. Donc si l'un dépend de l'autre, c'est potentiellement un soucis.

[camillemonchicourt]

Concernant les éventuels triggers, ils sont à mettre en place au niveau de Occtax et pas de la Synthèse (même si les champs sont très similaires).

Concernant des exemple, il y a celui-ci que j'évoquai plus haut qui créer une validation avec la valeur par défaut lors de la création d'une occurrence : https://github.com/PnX-SI/GeoNature/blob/master/contrib/occtax/data/occtax.sql#L916-L920

Et il y a tous ceux d'update dans ce même fichier qui permettent de mettre à jour la Synthèse quand on modifie une occurrence dans Occtax. Mais comme dit Gil, attention, on a passé pas mal de temps à caler ces triggers qui sont de 3 niveaux (Relevé / Taxon / Dénombrement) et doivent être remis à plat dans la Synthèse.

[DonovanMaillard]

Dans les champs devant entrainer une revalidation, pour moi : stade, méthode, altitude, geom, dates, espèce, méthode de détermination, preuves et déterminateur.

Sur le reste, le principe de faire reposer ça sur un trigger mis en place ou non par chaque administrateur semble le plus simple, et le moins contraignant pour l'ensemble des utilisateurs.
pour ma part la question se posera. Mais sans triggers, puisqu'il s'agira que de données d'imports ^^ donc je vais pas vous embêter, je vais devoir définir une politique et faire mes scripts...

[gildeluermoz]

En fait cette discussion concerne moins le module de validation, qui ne peut pas faire faire ce travail, que le reste de GN et notamment occtax.

[sig-pnrnm]

Salut à tous,

Après une nuit de réflexion, j'ai une proposition qui peut peut-être satisfaire tout le monde, et qui en terme de développement serait ultra basique.

Je propose que la vue de validation, dans le module validation, affiche une icone sur les observations dont la date de modification (meta_update_date) est postérieure à la dernière date de validation (meta_validation_date), et que le module permette d'utiliser cette info comme critère de filtre, afin de passer l'ensemble des données concernées en revue.

(en ajoutant, au survol du crayon, le tooltip "donnée modifiée depuis sa dernière validation")

Sinon, ça me pose aussi la question de l'affichage/archivage des modifications des données : je crois que ce sujet avait été évoqué par @jbrieuclp ?

[sig-pnrnm]

Sinon, ça me pose aussi la question de l'affichage/archivage des modifications des données : je crois que ce sujet avait été évoqué par @jbrieuclp ?

Je viens de retrouver l'issue en question :
PnX-SI/GeoNature#339

Il y a beaucoup de notions à intégrer pour moi : est-ce que les tables en question sont opérationnelles, et permettent-elles d'avoir un suivi des modifications d'une donnée ?

[camillemonchicourt]

Pourquoi pas. Ça peut etre une évolution bien transversale, globale et générique sans toucher aux modules sources.

Par contre je pense qu'on a fait une erreur en ajoutant une coche "En attente de validation" car ça alourdit l'interface et complexifie la compréhension.
Étant un filtre on aurait du mettre ça dans le bloc de droite avec les autres filtres, quitte à ajouter une partie VALIDATION en premier avec un filtre "Statut de validation" qui serait sélectionné par défaut sur "En attente de validation" (id_nomenclature en paramètre) et qui aurait permis de facilement filtrer sur un autre statut ou aucun statut.

De la même manière on pourrait ajouter un filtre en dessous "Données modifiées depuis la dernière validation".

Oui l'historisation des modifications est opérationnelle dans une table verticale et mise en place sur Occtax.

[JulienCorny]

oui je pense aussi finalement que ce serait mieux de mettre tous les filtres au même endroit, avec le filtre sur les statuts de validation tout en haut, bien en évidence, et ajouter un filtre "données modifiées depuis la dernière validation".
Je trouve bien aussi l'idée d'ajouter une icône dans la liste des données pour indiquer les données modifiées depuis leur dernière validation.
Je vais intégrer tout ça.

[JulienCorny]

Bonjour à tous,
J'ai intégré l'ajout d'un icône dans la liste des observations pour indiquer les données modifiées depuis leur dernière validation.
Je me suis basé sur la valeur meta_update_date : si meta_update_date > validation_date alors l'icône apparaît pour dire que les données ont été modifiées depuis la dernière validation.
Le problème est que meta_update_date est une métadonnée, donc lorsque j'édite une observation dans Occ_tax (modification du nom du taxon ou autres, par exemple concernant les méthodes d'observations), la meta_update_date est impactée sur toutes les observations du jeu de données, donc l'icône apparaît à gauche de toutes les observations issues du jeu de données.
Comment pourrait-on faire pour récupérer une date de modif propre à l'observation?

[camillemonchicourt]

Le champs synthese.meta_update_date ne concerne que l'occurrence et pas tout le jeu de données.

[camillemonchicourt]

Par contre, si on modifie une occurrence d'un relevé, alors le trigger Occtax>Synthèse modifie la date_update de toutes les occurrences du relevé.
Donc c'est un petit effet de bord qui sera potentiellement à améliorer au niveau du trigger Occtax>Synthèse.

@JulienCorny, reste à modifier le module pour se baser sur la date_update de l'occurrence et non pas celle de son JDD ?

[TheoLechemia]

Le soucis vient de la manière dont est fait l'update en utilisant SQLAlchemy. Quand on met à jour un relevé (au niveau du relevé lui même, de l'occurrence ou du dénombrement), on passe par l'unique route : https://github.com/PnX-SI/GeoNature/blob/master/contrib/occtax/backend/blueprint.py#L273.  Via le jeu des relationships, on met à jour les 3 tables d'occtax, même si on ne modifie que le taxon.  Les "meta_update_date" des 3 tables sont mis à jour. Donc pas possible en l'état de détecter un changement sur UNE occurrence d'un relevé.

[camillemonchicourt]

OK donc c'est bien gn_synthese.synthese.meta_update_date qui est utilisé et donc pour le moment on assume ce petit effet de bord où la date de toutes les occurrences d'un relevé sont modifiées même si on n'en modifie qu'une.