Feat : Ajout des champs additionnels - Enhancement

[Adrien-Pajot]

Demande d'un BE (Emberiza) Je ne sais pas si cela a déjà été discuté mais pour suivre les évolutions d'OccTax, il pourrait être intéressant d'avoir une correspondance au niveau des champs additionnels. Chaque champ ajouté en web se retrouverait en mobile, ou au moins il serait possible d'en paramétrer sur les mobiles et puis de faire une correspondance ?

[DonovanMaillard]

C'est prévu et ca sera fait courant 2022. Nos prochaines commandes (j'ai.un cahier des charges à finir pour lundi prochain ;) ) vont commencer à réaligner le module Web et le module mobile dont on veut qu'ils soient les plus cohérents possibles, et que le mobile ne soit qu'un support différent mais avec des fonctionnalités a l'identique.

Dans ce cadre la, la saisie en texte des observateurs, les champs additionnels, le lien entre dataset/liste de taxons etc sont prévus. Possiblement l'arrivée des médias (pas inclu dans notre previsionnel, à voir selon reliquats), voire des donnees en ligne/polygones.

[camillemonchicourt]

En effet, depuis plusieurs versions de GeoNature, des champs additionnels peuvent être ajoutés dans Occtax, globalement ou par JDD. Il est possible d'ajouter des champs additionnels au niveau du relevé, au niveau du taxon ou au niveau du dénombrement. Détail sur https://docs.geonature.fr/admin-manual.html#administration-des-champs-additionnels. Les valeurs renseignées au niveau de chaque observation pour ces éventuelles champs additionnels sont stockées dans des champs JSON au niveau des tables des relevés, des taxons ou des dénombrements.

Les champs additionnels sont récupérables dans l'API : https://demo.geonature.fr/geonature/api/gn_commons/additional_fields

[sgrimault]

L'intégration des champs additionnels est en cours. La partie synchronisation et gestion locale sont déjà terminées :

• Appel à GET -> /api/gn_commons/additional_fields
• Stockage local en base de données des champs additionnels, des valeurs possibles, du code_object correspondant et du module de rattachement (ici "occtax"). L'attribut code_object est utilisé comme un "filtre" pour distinguer les champs à afficher dans le bon écran ("Informations" ou "Dénombrement").

Le mapping dans les écrans "Informations" et "Dénombrement" est en cours avec en premier lieu, la gestion des types simples (par exemple : widget_name: "text"). Coté "Occtax", ce sera vu comme un champ éditable comme tous les autres, qui sera typé, de façon à avoir une gestion homogène et transparente des champs présents dans les écrans de type "formulaire" ("Informations" et "Dénombrement"). Ainsi coté "Occtax" nous avons déjà les types de champ suivants :

• TEXT : champ de saisie de type texte simple
• TEXT_MULTIPLE : champ de saisie de type texte, pouvant s'étaler sur plusieurs lignes
• NOMENCLATURE_TYPE : champ de saisie de type liste déroulante mappée avec un type de nomenclature (par exemple ETA_BIO).
• MIN_MAX : champs de saisie permettant de gérer une plage de valeur minimale et maximale de type entier numérique
• MEDIA : "champ de saisie" (ce n'est pas vraiment un champ de saisie… 😅) qui permet de gérer les médias sous forme de grille

Avec les types de données suivants :

• PropertyValue.Text : de type texte
• PropertyValue.Date : de type date (stockage au format ISO)
• PropertyValue.StringArray : de type tableau de chaînes de caractères
• PropertyValue.Number : de type valeur numérique
• PropertyValue.NumberArray : de type tableau de valeurs numérique
• PropertyValue.Nomenclature : de type nomenclature (afin de stocker à la fois le libellé du champ mais aussi son identifiant coté base de données)
• PropertyValue.Taxa : pour gérer une liste de taxons (occurrences de taxon)
• PropertyValue.Counting : pour gérer une liste de dénombrements rattachés à un taxon (occurrence de taxon)
• PropertyValue.Media : pour gérer une liste de médias (aussi bien les métadonnées que le fichier lié au média)

Pour la gestion des champs additionnels, il y a aura donc de nouveaux types de champ qui vont être implémentés :

• Liste simple
• Liste à choix multiples
• Liste de cases à cocher
• Liste de radio boutons

Les types texte et nomenclature sont déjà implémentés. Avec de nouveaux types de données, je pense notamment au type booléen qui n'existe pas encore.

Toujours avec la même idée de mutualiser et uniformiser la gestion des champs de saisie dans l'interface. Actuellement seuls les écrans "Informations" et "Dénombrement" fonctionnent de cette manière. L'écran de l'étape 1 n'est pas du tout dynamique et impose seulement la liste des observateurs, le choix du jeu de données et la date du relevé. La première implémentation de la gestion des champs additionnels ne concernera donc que les écrans "Informations" et "Dénombrement". L'écran de l'étape 1 devra être revu si on souhaite aussi injecter les champs additionnels à ce niveau là.

Dernier point, les champs additionnels permettent de faire aussi un lien avec la nomenclature. Coté API il y a des attributs supplémentaires pour faire ce lien (exemple : code_nomenclature_type). Mais son fonctionnement est un peu déroutant :

• Le champ additionnel peut préciser le label (alors qu'on a déjà le label coté nomenclature)
• L'attribut field_name sert à faire le mapping et est utilisé comme clé de la propriété à stocker coté relevé. Il diffère du code utilisé coté nomenclature.
• L'attribut field_values peut être renseigné ce qui peut être en conflit avec les valeurs possibles issues de la nomenclature.

Idéalement, ce serait simplement d'indiquer que le champ additionnel est de type "nomenclature", dont field_name indique le code mnémonique du type de nomenclature à cibler et éventuellement que l'on souhaite changer son libellé par défaut (issue de la nomenclature) via l'attribut field_label. Coté mapping, idéalement, ce serait de toujours s'appuyer sur l'attribut field_name comme clé de la propriété à ajouter au relevé. Globalement, on ne devrait utiliser que des codes (et pas des identifiants de base) coté relevé pour les champs de saisie (lié à la nomenclature ou non). Exemple de mapping qui existe aujourd'hui et qui empêche d'avoir un fonctionnement totalement dynamique sur la gestion du relevé où les types de nomenclature sont mappés "en dur" comme suit coté relevé :

• TYP_GRP -> id_nomenclature_grp_typ
• ETA_BIO -> id_nomenclature_bio_condition
• METH_DETERMIN -> id_nomenclature_determination_method
• METH_OBS -> id_nomenclature_obs_technique
• NATURALITE -> id_nomenclature_naturalness
• OCC_COMPORTEMENT -> id_nomenclature_behaviour
• PREUVE_EXIST -> id_nomenclature_exist_proof
• STATUT_BIO -> id_nomenclature_bio_status
• OBJ_DENBR -> id_nomenclature_obj_count
• SEXE -> id_nomenclature_sex
• STADE_VIE -> id_nomenclature_life_stage
• TYP_DENBR -> id_nomenclature_type_count

Jusqu'à présent les types de nomenclature étaient "imposés" dans la constitution d'un relevé. Donc ce mapping "en dur" est acceptable en l'état. Mais avec la gestion des champs additionnels (dont le fonctionnement est totalement dynamique) permettant de construire des interfaces plus dynamiques, potentiellement liés à des types de nomenclatures change le fonctionnement actuel sur la partie nomenclature. Donc la première implémentation des champs additionnels ne supportera pas les champs additionnels de type "nomenclature".

Désolé pour la longueur…

[TheoLechemia]

Bonjour Sébastien, voici quelques réponses :

Le champ additionnel peut préciser le label (alors qu'on a déjà le label coté nomenclature)_

Effectivement. Là, on va privilégier le label fourni par le champs additionnel (une nomenclature pouvant être utilisée dans différents contextes, on veut parfois préciser son utilisation dans le contexte du protocole / formulaire)

L'attribut field_values peut être renseigné ce qui peut être en conflit avec les valeurs possibles issues de la nomenclature.

Effectivement, le backoffice est très générique et on peut renseigner le "valeurs" même si on a dit que c'était un champs de type "nomenclature". Ces infos ne sont pas à prendre en compte : si le type de widget est "nomenclature" alors on ne prend que les valeurs renvoyé par l'API des nomenclatures

L'attribut field_name sert à faire le mapping et est utilisé comme clé de la propriété à stocker coté relevé. Il diffère du code utilisé coté nomenclature.

Oui c'est bien de le champs field_name qu'il faut utiliser comme clé de champs JSON additional_fields de la table correspondante. Je ne comprend pas le "il diffère du code utilisé côté nomenclature" ? Pour ce champs, la liste déroulante doit être constituée des valeurs que contient la liste associé au code nomenclature du champs additionnel. Ce qui nécessite que cette nomenclature ai été synchronisée au préalable côté mobile j'imagine ?

Coté mapping, idéalement, ce serait de toujours s'appuyer sur l'attribut field_name comme clé de la propriété à ajouter au relevé.

oui

De ce que je lis, il y a aussi un élément qui semble manquant : il y a des champs additionnels globaux (à afficher tout le temps), et des champs additionnels associé à des jeux de données (à n'afficher que se le JDD est sélectionné). Côté API, si le tableau datasets est vide, c'est que c'est un champs global, sinon il n'est à afficher que sur les JDD présent dans ce tableau

[TheoLechemia]

Autre vigilance : depuis la version 2.12, on a améliorer le "typage" du champs field_values. Pour les widget de type select, multiselect, checkbox et radio, le champs field_values doit contenir un tableau de dictionnaire avec les clés label et value. Il n'est plus possible de renseigner ce champs avec un simple tableau de valeur, mais on a en revanche pas reprise les champs existants. Du coup côté frontend, il y a une transformation des tableau en tableau de dictionnaire avec les clés label et value. J'imagine qu'il faudra que tu fasse pareil côté mobile

[sgrimault]

Bonjour @TheoLechemia,

Merci pour tes retours. Je suis en train de revoir le modèle pour associer les champs additionnels avec les jeux de données. On pourra alors appliquer des filtres selon le jeu de données. Pour la gestion des valeurs possibles (via l'attribut field_values), je construis systématiquement une liste de couples "clé", "valeur" où la valeur prend automatiquement le nom de la clé si aucune valeur n'a été définie. Le modèle accepte actuellement ces deux constructions (liste de valeurs simples, ou liste de couples).

Concernant la partie nomenclature, je me disais si ce ne serait pas plus simple de déclarer en plus dans la configuration les nomenclatures que l'on souhaite afficher pour la partie "Information" et "Dénombrement". Actuellement, on peut configurer cette liste via le paramètre nomenclature (cf. Nomenclature settings). Actuellement cette liste est fermée et n'accepte pas des déclarations supplémentaires. Mais on pourrait imaginer de la rendre ouverte et ainsi ajouter les déclarations de la nomenclature que l'on souhaite afficher ou non (en les omettant). Le souci de cette approche est qu'actuellement on a un mapping en dur sur les attributs à insérer dans le JSON du relevé. Exemple, le type de nomenclature ETA_BIO est traduit par id_nomenclature_bio_condition coté relevé… Idéalement, il faudrait tout simplement garder le code mnémonique de la nomenclature afin d'avoir un modèle souple et extensible.

L'autre approche serait de considérer que tous les champs des écrans "Information" et "Dénombrement" soient considérés comme des "champs additionnels" (avec le code du champ via l'attribut field_name, son libellé via l'attribut field_label, son type via l'attribut widget_name, etc.). Les types de nomenclature "éditables" seraient considérés comme un champ comme un autre, typé, avec ses propriétés. On aurait du coup quelque chose de totalement dynamique et pilotable par configuration et la construction de ces écrans serait uniforme. Mais ça implique de revoir je pense des choses coté GeoNature, notamment au niveau du mapping.

[camillemonchicourt]

Dans la 2.7.0-rc1, un paramètre nomenclature/additional_fields a été ajouté (à false par défaut). OK si c'est pour la phase de test, mais sinon, selon moi ce n'est pas utile de garder ce paramètre pour la release 2.7.0, car les champs additionnels s'affichent si certains ont été définis, ou pas si il n'y en a aucun définis au niveau d'Occtax ou d'un JDD spécifique.

[DonovanMaillard]

Oui, pas de raisons de les désactiver selon le terminal utilisé :)

[camillemonchicourt]

Dans la 2.7.0 les champs additionnels ont été intégrés sur les taxons et les dénombrements. Mais pas encore sur les relevés. A développer dans une prochaine version, ainsi que la prise en charge de certains attributs de ces champs additionnels (obligatoire, ordre, etc...). On pourra alors supprimer le paramètre additional_fields ou au moins le passer à TRUE par défaut.