Occtax multi records

[jbrieuclp]

cf. #758
C'est normalement ok sur le côté fonctionnement, il reste des petits éléments fonctionnels à ajouter.

[camillemonchicourt]

Merci, c'est une très bonne base.

Voici les points que j'ai noté :

• Repositionner le bouton d'accès aux intersections géographiques, au niveau de l'altitude
• Remettre les contrôles des champs MIN et MAX et leur cohérence. Comparaison Altitude Max inférieure à altitude min. Quand on renseigne le Dénombrement min, cela bougeait le Dénombrement max avec le même nombre etc...
• Ajout d'un dénombrement : Replier le premier et déplier le nouveau à remplir
• Adapter les valeurs de nomenclatures au taxon selectionné
• Utiliser Material mélangé avec Bootstrap ?
• Pertinence d'afficher le Nom valide ? Mettre un paramètre pour la masquer comme les autres champs, car je trouve que cela complexifie le formulaire et peut apporter de la confusion
• Vérifier le fonctionnement Responsive sur smartphone (ça a l'air pas mal déjà)
• Clarifier le fonctionnement entre ENREGISTRER, ANNULER, QUITTER. De mon usage, dans un formulaire web, quand je clique sur ENREGISTRER, j'ai l'habitude de QUITTER le formulaire, c'est la dernière étape quand j'ai fini. Pour le relevé, plutôt indiquer "TAXONS >>" ou autre du genre. Une fois sur le taxon, je ne comprends pas comment je termine et QUITTE le formulaire. L'enregistrement au fur et à mesure devrait être plus transparent pour l'utilisateur, sans forcément lui afficher ENREGISTRER. A voir comment rendre ça plus clair.
• Remettre l’enchaînement de saisie de relevé

[DonovanMaillard]

J’ajoute un manque vu sur la version actuelle : ajouter le sample number proof quand la conf le prévoit. ;)

[TheoLechemia]

Il y a pas moyen de faire une seule route pour le post et l'update.

[TheoLechemia]

Revoir la docstring

[TheoLechemia]

Ces imports sont utilisés ?

[camillemonchicourt]

Suite à nos tests et à des retours utilisateurs, @TheoLechemia a complété cette PR dans la branche dédiée (https://github.com/PnX-SI/GeoNature/commits/jbrieuclp-occtax-multi-records) :

• Simplification ergonomique, en réduisant le nombre de boutons et leur fonctionnement (Fermer / Annuler / Valider)
• Suppression du relevé si on clique sur Annuler (si on a 0 taxon sur le relevé). A voir si on doit gérer cela différemment. Supprimer tout le relevé et ses taxons si on annule ? Et si on est en mode Edition et qu'on annule, cela devrait annuler toutes les modifications mais c'est pas le cas et pas possible avec l'enregistrement continu. A creuser.
• Validation globale du relevé possible uniquement si on a ajouté au moins un taxon, pour éviter de créer des relevés sans taxon (même si cela reste possible si on quitte le formulaire après avoir créé le relevé et sans avoir ajouté un taxon, à voir si on doit aller plus loin dans le blocage, en supprimant les relevés orphelins d'une autre manière ?)
• Simplification des vocabulaires (Observations devient Taxons notamment pour éviter des confusions)
• Amélioration du responsive et des scrolls sur la liste des relevés et sur le formulaire
• Message d'alerte si on ajoute un taxon déjà existant dans le relevé
• Focus sur le bouton AJOUTER CE TAXON après avoir choisi un taxon pour faciliter la saisie rapide au clavier
• Améliorations de la fiche info d'un relevé dans Occtax
• Corrections diverses

A VENIR en complément :

• Passage sur la V2 du standard occurrence de taxons / Comportement + Habitat... (dans une branche dédiée - https://github.com/PnX-SI/GeoNature/tree/occtax-v2)
• Affichage d'une info (optionnelle) quand on sélectionne un taxon, depuis un attribut TaxHub
• Corrections mineures d'ergonomie, de responsive, de scrolls...
• Corrections diverses (MAJ altitude, MAJ dates...)

A VOIR :

• Action ANNULER à améliorer/clarifier, ou alors on abandonne la possibilité d'Annuler
• Relevé sans taxon non permis ?
• Paramétrage des valeurs par défaut (à minima supprimer GÉOMÉTRIE, cohérence avec la logique d'Occtax ?)

[jbrieuclp]

Salut,
Merci du retour pour l'intégration de cette PR.

Par rapport aux points du "à voir", ce n'est peut être pas un cas d'application que vous pouvez avoir au PNE, mais en entomo, du moins au Gretia, les collègues ont pris l'habitude de créer des relevés vierges au retour du terrain, de stocker les ID occtax dans les tubes de bestioles collectées et de compléter les relevés vierges dans un second temps après avoir réalisé les déterminations en labo. Comme les tubes contenant les bestioles par groupe taxo sont dispatchés auprès des différents spécialistes des groupes, les déterminations et les saisies peuvent se faire longtemps après la création du relevé et par des personnes différentes.

Pour le second point, pouvoir permettre de dupliquer une géométrie permet de créer des relevés de suivis plus facilement. Ok dans le principe d' 1 géométrie = 1 relevé, mais quand la date est différentes on est bien sur 2 relevés de même géométrie.

Donc il peut être préférable de voir pour un paramétrage de ces fonctionnalités plutôt que de les abandonner.

[camillemonchicourt]

Globalement l'ergonomie du formulaire avec 2 onglets est bien mieux, plus lisible, plus agréable.
Par contre, comme discuté au tout début dans le ticket initial, l'enregistrement continu pose des soucis techniques et rend la compréhension du formulaire plus complexe.
On gagne en ergonomie mais on perd en intuitivité. Après pas mal de tests de nombreux utilisateurs, des questions d'usage reviennent souvent et on n'arrive pas à se caler sur des messages des boutons simples et claires.
La logique classique d'un formulaire WEB est de poster à la fin de la saisie complète d'un formulaire, donc poster au fur et à mesure pose différents soucis.
Avec l'enregistrement continu, il est plus complexe de comprendre ce qu'il se passe, à quel moment, comment annuler, valider, modifier, quitter. Et il n'est pas non plus souhaitable de devoir expliquer tout le fonctionnement technique à l'utilisateur pour qui cela doit être simple et transparent.
Même si les pertes de données lors de gros relevés évoquées dans le ticket justifient l'enregistrement continu, peut-être qu'il aurait mieux valu garder un POST global mais enregistrer en continu au niveau du navigateur (local storage ou autre).

Bref, on pense avoir pas mal simplifié et clarifié mais ce n'est pas encore vraiment satisfaisant.
A voir à l'usage, mais on y perd sur certains aspects et en simplicité de compréhension.
Par exemple, on ne peut plus ANNULER une saisie car c'est incompatible avec le fonctionnement de l'enregistrement continu où l'on ne peut pas savoir ce que l'on a modifié ou pas. Plutôt que de faire un système mixte, on va donc finalement retirer le bouton ANNULER.

Concernant les relevés sans taxon, c'était un choix de principe d'Occtax et avoir des relevés orphelins peut poser des soucis et des incohérences de données. Ce serait vraiment dommage de le permettre car ça créerait pas mal de relevés sans taxon involontaires qui vont trainer.
On pourrait mettre un paramètre mais ça va alourdir la maintenance, les tests etc...
Si un agent veut un id_relevé, il peut créer un relevé et mettre un taxon avec le genre et venir compléter quand il a ses déterminations.

Pour la duplication de la géométrie, Occtax n'est pas conçu pour faire des suivis donc c'est discutable vis à vis des objectifs d'Occtax. Et la fonction MES LIEUX en cours de finalisation va permettre de stocker ses lieux persos fréquemment utilisés.
Mais en effet, comme une Occurrence de taxons n'est pas qu'une localisation, mais la combinaison d'un localisation à une date, OK pour garder la duplication d'une géométrie.

Par contre, il faudra potentiellement revoir l'outil de paramétrage des valeurs par défaut, car on a eu plusieurs retours de tests qui ne comprenaient pas bien son fonctionnement. Ça pourrait certainement être simplifié et le principe de GeoNature est de ne pas avoir de menus ou d'outils de paramétrages nécessitant un manuel utilisateur. Hors là on commence à y passer avec cet outil de paramétrage. Donc à limiter au maximum.
En attendant le fait de pouvoir activer ou non ce menu limite le problème.

[jbrieuclp]

Concernant les relevés sans taxon, c'était un choix de principe d'Occtax et avoir des relevés orphelins peut poser des soucis et des incohérences de données. Ce serait vraiment dommage de le permettre car ça créerait pas mal de relevés sans taxon involontaires qui vont trainer.
On pourrait mettre un paramètre mais ça va alourdir la maintenance, les tests etc...
Si un agent veut un id_relevé, il peut créer un relevé et mettre un taxon avec le genre et venir compléter quand il a ses déterminations.

Si un agent veut un id_relevé, il peut créer un relevé et mettre un taxon avec le genre et venir compléter quand il a ses déterminations.
Puis supprimer la données saisie au genre pour la remplacer par la bonne détermination à l'espèce. Sauf que quand il aura cliqué sur le bouton de suppression de son unique taxon, le trigger qui supprime les relevés de 0 taxon lui aura fourbement supprimé son relevé et ce sans aucune explication, vu que c'est un trigger.
Ce qui va créer un agent qui ne va pas comprendre ce qui lui est arrivé, qui va être énervé et qui va ragequit en grognant "c'est de la merde !".

[camillemonchicourt]

Justement pour éviter les relevés sans taxon, on a bloqué la possibilité de supprimer le dernier (ou unique) taxon d'un relevé. On peut seulement le modifier.

Mais je comprends ton cas d'usage mais c'est dommage de générer par erreur des relevés sans taxons à tous les utilisateurs de GeoNature pour autant.

Un paramètre permettant ou non les relevés sans taxon serait pertinent mais je crains les galères de maintenance et tests mais pourquoi pas.

[camillemonchicourt]

Autre point de vigilance, pas idéal et qui va alourdir la maintenance et les tests : les routes.
On a gardé les anciennes routes de POST global pour que Occtax-mobile puisse continuer à fonctionner.
Et créé des nouvelles routes pour Occtax-web qui poste de manière séparée les relevés et les occurrences.
Mais du coup cela fait maintenir et tester des routes dont certaines ne sont pas utilisés en web, donc avec le risque de les zapper.
De plus ce sont les anciennes routes sur lesquelles il y a des tests automatisés, mais il n'en a pas été mis en place sur les nouvelles utilisées par la refonte d'Occtax-web.

Donc pas idéal et pas pérenne comme solution.

[camillemonchicourt]

Pour les problèmes d'ergonomie et de routes liés à la mise en place de l'enregistrement continu, une autre piste discutée avec @amandine-sahl et @jpm-cbna serait d'enregistrer les données au fur et à mesure de la saisie dans une table temporaire. Si on valide la saisie, on vide la table temporaire. Si la saisie n'aboutit pas, que le réseau est coupé ou autre, alors quand on revient sur le formulaire Occtax, il nous indique qu'on a un relevé en cours non terminé et nous propose de le recharger pour le terminer.

[jbrieuclp]

Il y a maintenant plusieurs structures qui se sont basées sur l'outil et nos différents collègues et utilisateurs de l'appli n'ont pas forcément la même manière de travailler selon qu'on bosse sur de la macrofaune, de la bota ou de l'entomo.
Avec tous les systèmes de vérifications et de triggers, lors de l'enregistrement d'une donnée, la base est très lente. Quand on se retrouve à enregistrer un relevé à plusieurs taxons l'enregistrement met un temps monstre et si on a moins de chance, elle peut finir par planter (time out du backend ?). #997
Après des chasses de nuit, j'ai vu passer des relevés à plus de 150 taxons, la saisie et l'enregistrement de ce relevé aurait été impossible en oneshot. D'ailleurs, même avec 30 taxons ça plantait 1 fois sur 2. Sommes-nous un cas isolé ?
En bota, si l'appli est utilisée, il est aussi possible d'avoir autant de taxons pour un relevé.

[camillemonchicourt]

Oui le problème d'utiliser le local.storage ou une table temporaire pour l'enregistrement continu est que cela peut régler les petites pendant la saisie mais pas forcément à l'enregistrement.
A voir à l'usage. Pour le moment on va rester comme ça mais ce n'est pas totalement satisfaisant au niveau du doublement des routes, des tests automatisés et de l'intuitivite, et on verra comment on peut faire évoluer ça plus tard.

[DonovanMaillard]

Sommes-nous un cas isolé ?

Nous avons également beaucoup de chasses nocturnes et des relevés de 70-100 taxons sans soucis pour notre part, pas de plantages particuliers. En revanche, ce n'est pas à proprement parler des données occassionnelles, et on se pose toujours la question d'un module dédié à ces chasses nocturnes, avec ses champs masqués et ses nomenclatures par défaut pour se faciliter la saisie. Le module étant malgré tout très proche d'occtax je me dis qu'il pourrait être assez facile à faire techniquement, il reste surtout à trouver du temps pour le faire et, surtout.... pour le maintenir ensuite.