Module de validation pour GeoNature-citizen

[hypsug0]

Dans le cadre du projet “Un dragon dans mon jardin”, la SHF souhaite contribuer au développement de GeoNature-citizen par l’ajout d’une fonctionnalité simple de “vérification/identification” des données par un panel de validateurs. Dans ce projet, déjà en place sur une autre application, un panel d’identificateur fait aujourd’hui de l’identification sur photos à partir des observations saisies par des contributeurs bénévoles. Il s’agit de mettre en place, dans un premier temps, cette fonctionnalité simple.

Pour cette nouvelle fonctionnalité, il est proposé de créer côté frontend un nouveau dashboard d’administration des données sur la base du dashboard utilisateur existant, améliorant ainsi grandement l’ergonomie de la gestion des observations par rapport au backoffice actuel (Flask-admin).

A développer

La nouvelle fonctionnalité se voudra dans un premier temps simple:

• Une personne définie comme validateur (nouveau champ dans gnc_code.t_users aura la possibilité d’éditer une donnée saisie par un contributeur "lambda". Il pourra ainsi corriger la donnée saisie par un autre contributeur. Une case à cocher (valeur vrai par défaut) pourra définir le statut de validation (oui/non) de l'observation.

• Le formulaire d’édition de la donnée contiendra également un champ Avertir l'observateur coché par défaut. L’observateur (si inscrit ou email renseigné) sera alors averti par email de la "validation" de sa donnée sur la base d'une liste de modèles prédéfinis :

  • L’espèce que vous avez observée est bien un[e] [nom de l’espèce]. Merci pour votre participation !
  • Nous avons bien reçu votre photo, merci beaucoup pour votre participation. Il s’avère que l’espèce que vous avez observée est un[e] [nom de l’espèce].
  • L’identification de l’espèce que vous avez observée est difficile d’après cette ou ces photos, nous continuons nos recherches...
  • Désolé, l’identification de l’individu que vous avez observée est trop difficile. Pouvez-vous essayer de le photographier, à nouveau, lui et/ou ses congénères ?
  • L’espèce que vous avez observée n’est ni un amphibien, ni un reptile.
  • Les photos que vous nous avez envoyées correspondent à des espèces différentes. Pourriez-vous les poster séparément ?

• Pour un minimum d’historique sur la donnée, il conviendra d’ajouter et peupler automatiquement les champs créé par (created_by/mis à jour par (updated_by) à la table gnc_obstax.t_obstax.

En perspective

Si ce premier développement d’un dispositif de validation/modification des données se veut volontairement simple, il est intéressant de garder à l’esprit des perspectives de développements à moyen terme sur cette problématique comme:

• Ajout d’un dispositif de validation par la communuauté des observateurs (proposer aux contributeurs de confirmer les données d’autres contributeurs)

Pour le moment, la validation telle que actuellement pratiquée dans GeoNature (pas d’édition de la donnée mais définition d’un statut de validation) sera à mener prioritairement dans GeoNature.

[lpofredc]

Il est choisi de modifier le statut de validation booléen par 4 choix:

• Non validée (aucun processus de validation) -> Valeur par défaut
• Validée (Donnée correcte, confirmée)
• Invalide (Donnée incorrecte, fausse)
• Non validable (Identification / confirmation impossible en l'état, demande d'informations complémentaires).

Toutes les données seront affichées, le statut de la donnée sera visiblement identifiable (code couleur et/ou pictos)

[LoanR]

Bonjour tout le monde !

C'est Yaal Coop qui a été contacté pour cette issue. Je poserai donc ici les réflexions / questions qu'on a sur la conception.

Ce module de validation sera activable par un feature flag dans la configuration.

Quelques changements sur les modèles sont requis :

• un booléen verifier sur User qui donne la capacité de valider (corriger, ou "demander de l'aide") les observations
• un "choice" sur Observation qui indique son état de validation (les 4 choix énoncés plus haut)
• une clé étrangère de User sur Observation pour stocker le (dernier, dans le cas d'une identification complexe) User ayant validé l'observation

Une question subsiste sur la migration à appliquer sur Observation sur son "état".
Imaginons une instance qui tourne depuis un certain temps sur laquelle un certain nombre d'observations ont été enregistrées. Le module est par la suite activé. Les nouvelles observations passent par le processus normal de validation. Mais pour les observations historiques, faut-il les placer en "non validée" et ainsi demander un certain volume de travail aux validateurs (comme vu plus haut, elles restent visible, il n'y a qu'un indicateur visuel qui change), ou bien les passer automatiquement à "validée" et ainsi entériner le passif de l'instance en question ?
Il est également possible que ce cas n'existe pas et que dans le cas de la SHF par exemple qui n'a pas d'historique pour le moment, il n'y ait donc pas de migration.

[camillemonchicourt]

Selon toutes données historiques dont on ne sait pas si elles ont été relues doivent être mises à "Non validées".

[mvergez]

Salut !

Merci pour ces avancées !

Petite question : tu prévois de lancer les migrations de base de données à l'activation du module de validation ou à l'installation de citizen ?

[LoanR]

Je pensais lancer les migrations au déploiement, jouées au démarrage avec la nouvelle version.
L'usage de ces modifications sera toujours derrière un test de la conf, donc invisible pour les autres instances.

Vous procédez autrement généralement ? J'ai l'impression qu'avoir des instances avec des DB différentes, c'est prendre un risque d'hétérogénéité des données, de debug, même si on stocke des données inutiles...

[mvergez]

C'est parfait ! C'était juste pour être sûr :)

[LoanR]

Hello, j'ai référencé un draft pour le suivi. @camillemonchicourt a déjà commencé à y réagir.

J'ai deux trois à vous soumettre :

Les statuts de validation

Si je m'en réfère au besoin de la SHF (en description plus haut) et plus particulièrement concernant les messages envoyés à l'observateur, j'ai besoin de 5 statuts que j'ai nommés autocratiquement pending, unverifiable, off-topic, multiple, approved. Voilà pourquoi 5 avec les différents cas de figure :

• Une observation avec identification qui est validée par un "validateur", le défaut pending passe à ➡️ approved

L’espèce que vous avez observée est bien un[e] [nom de l’espèce]. Merci pour votre
participation !

• observation avec identification erronée corrigée par un "validateur", pending ➡️ approved (puisque la donnée devient vraie, il semble inutile de garder un trace du fait qu'elle était fausse au départ)

Nous avons bien reçu votre photo, merci beaucoup pour votre participation. Il s’avère que l’espèce que vous avez observée est un[e] [nom de l’espèce].

• observation sans identification qui est ensuite faite par un "validateur", pending ➡️ approved

Nous avons bien reçu votre photo, merci beaucoup pour votre participation. Il s’avère que l’espèce que vous avez observée est un[e] [nom de l’espèce].

• observation qui ne permet pas à un "validateur" de confirmer ou corriger l'identification, pending ➡️ unverifiable

L’identification de l’espèce que vous avez observée est difficile d’après cette ou ces photos, nous continuons nos recherches...

• observation déjà notée identification difficile et qui ne peut toujours pas être validée, unverifiable ➡️ unverifiable

Désolé, l’identification de l’individu que vous avez observée est trop difficile. Pouvez-vous essayer de le photographier, à nouveau, lui et/ou ses congénères ?

• observation qui ne fait pas partie des espèces ciblées, pending ➡️ off-topic

L’espèce que vous avez observée n’est ni un amphibien, ni un reptile.

• observation avec des photos d'espèces différentes, pending ➡️ multiple

Les photos que vous nous avez envoyées correspondent à des espèces différentes. Pourriez-vous les poster séparément ?

Voilà donc pour la question du nombre de catégories.
Concernant le nommage, je suis prêt à en discuter. J'ai cherché à me rapprocher le plus possible de ce qui me semblait simple et proche du métier, plutôt que "valide", "invalide" et autres qui me semblaient très génériques.

Les observations hors-sujet et multiple

Dans les deux derniers cas d'observations, off-topic et multiple, que doit-on faire ? Je comprends l'intérêt d'afficher les observations, même celles qui ne sont pas encore approuvée par la communauté des "validateurs". Mais ces deux cas là ne sont pas vraiment des données pertinentes dans le cadre d'une enquête. Doivent-elles être visible pour l'observateur en question mais pas pour le reste des utilisateurs ? Doivent-elles être supprimées ? Y a-t-il des stats qui seraient faussées ?

Le nommage de la validation

Sans surprise, je ne suis pas très fan de ce qui tourne autour du mot "validation". Ça se voit dans le code, @camillemonchicourt l'a bien remarqué, et je ne suis pas sûr que ce soit le meilleur mot. J'ai tout de même modifié l'attribut d'Observation pour validation_status.
Néanmoins, pour lesObservation j'ai choisi les catégories décrites plus haut et pour les User, j'ai adopté verifier.
On peut me reprocher que dans le besoin on parle de "validateur" (on y parle aussi d'"identificateur", de "vérification", etc.) ce qui m'aurait donné en anglais des "validator" qui je crois n'existe pas, ou des validation_status comme "unvalidatable" et "non-validatable" que je trouve très lourds.
D'ou mes choix de mots.

Avez-vous des avis, des remarques sur ces trois points ?

👋

[camillemonchicourt]

Pourtant dans le domaine des données de biodiversité on utilise principalement le terme/concept de Validation.
Et des valeurs de validation sont définies dans les standards nationaux de données de biodiversité et sa partie VALIDATION : https://inpn.mnhn.fr/programme/donnees-observations-especes/references/validation.

Pour moi, il faut tout concentrer sur un seul terme qui fait référence : Validation, validator, validated...

Et pour être générique et plus proche des standards, je resterai sur les 4 statuts proposés plus haut par @lpofredc.

[LoanR]

La PR est prête pour review !
#361 (comment)

[LoanR]

(J'ai l'impression que les #261 et #360 ne sont toujours pas résolues, pas possible de faire des observations à l'ouest de Greenwich. Ça pourrait être un problème pour la SHF vu la taille des zones géographiques...)

[camillemonchicourt]

Intégré dans la version 1.0.0.

• Ajout d'un champs booléen gnc_core.t_users.validator
• Ajout des champs gnc_obstax.t_obstax.validation_status et gnc_obstax.t_obstax.id_validator
• Création d'une énumération validation_status ("NOT_VALIDATED", "INVALID", "NON_VALIDATABLE", "VALIDATED")
• Ajout des paramètres :
  • VERIFY_OBSERVATIONS_ENABLED (False par défaut)
  • VALIDATION_EMAIL

Si le module de validation est activé, les utilisateurs étant identifiés en tant que validateur ont accès à une interface de validation des données pour modifier leur statut de validation :