Occtax : Optimiser la lecture des occurrences déja saisies dans un relevé

DonovanMaillard commented 5 years ago

Un retour de Yann, mon collegue qui saisit des relevés à tour de bras, comprenant souvent plusieurs occurrences voire dizaines d'occurrences.

Il trouve que le fait de maintenir la carte sur 50% de la page pendant toute la saisie est inutile : une fois le relevé localisé, la moitié de l'écran est ignoré.

En parallèle de ca, une info qui serait intéressante (les occurrences déjà saisies) sont compactées dans un petit coin du formulaire.

Ainsi, si j'ai des males, des femelles, des juvéniles et des oeufs à saisir sur une espèce, je peux vite ne plus savoir ce que j'ai saisi ou non... et galérer à retrouver l'info (d'autant que les occurrences ne sont pas ordonnées à priori). Il serait donc plus optimal d'avoir une partie plus grande et plus précise pour recenser ce qui a déjà été saisi sur le relevé, avec certaines infos (sexe, stade, nombre par exemple).

La proposition qu'on a en tête après discussion avec camille :

Quand on arrive sur une saisie, on ne change rien, carte à gauche, formulaire à droite
Une fois la première occurence saisie, un accordéon s'ouvre sous la carte (et donc vient 'écraser' la carte). Cet accordéon liste la première occurrence qu'on vient de saisir avec quelques infos... et au fil des saisies dans le formulaire à droite, l'accordéon à gauche se complète.

En attendant vos remarques et avis! Désolé @TheoLechemia de toujours proposer de nouvelles modifs ;)

camillemonchicourt commented 5 years ago

Oui c'est une bonne piste, par contre :

Ainsi, si j'ai des mâles, des femelles, des juvéniles et des œufs à saisir sur une espèce, je peux vite ne plus savoir ce que j'ai saisi ou non... et galérer à retrouver l'info

Ça c'est autre chose, car les dénombrements par sexe se font au niveau d'une même saisie d'un taxon et non pas au niveau de plusieurs lignes de la liste des taxons.

YannBaillet-FlaviaAPE commented 5 years ago

En faite Camille, le point le plus important c'est de pouvoir rapidement évaluer si l'on a bien saisi les bons champs ! Pour le moment, je fais à chaque fois une extraction de ce que vient d'informatiser pour voir si je n'ai pas zappé un champ (comme on ne peut pas verrouiller les champs, au bout de la 100e espèce de papillons sur le relevé on a tendance à perdre le file et on ne sait plus vraiment si tous à bien été saisies !). Donc cet accordéon permettrait de rapidement contrôler notre saisie... Méaculpa pour mes idées saugrenues !!!!

Amegilla commented 5 years ago

Bonjour,

Je suis d'accord avec les échanges ci-dessus et je pense en effet que la lisibilité dans occtax peut-être améliorée. Je rajouterai que le classement des relevés sur la page d'accueil du module semble souvent obscur pour les utilisateurs et je propose de les classer par date de saisie (descendant). De cette façon lorsqu'on quitte le formulaire, on peut voir tout de suite le relevé que l'on vient d'enregistrer. C'est rassurant et assez intuitif. J'ai eu pas mal de retour de mes collègues qui ont à plusieurs reprises cru que ce qu'il venait de saisir n'avais pas été enregistré car non affiché ensuite.

Autre chose, moins important, est-ce qu'il est possible de remplacer la pagination par un déroulement infini. J'imagine un fonctionnement où la page ne charge que X données à l'ouverture et en charge plus que si l'on déroule plus loin que ce qui n'est déjà affiché ? Techniquement c'est possible ?

gildeluermoz commented 5 years ago

Ces 2 fonctionnalités étaient présentes dans GN1. La seconde était fournie par le plugin 'BufferView.js' dans ExtJS. Pour Angular j'ai trouvé qq chose qui ressemble : https://github.com/dhilt/ngx-ui-scroll Démo ici : https://dhilt.github.io/ngx-ui-scroll/#/ A voir si ça fonctionnerait dans GN2 et/ou s'il y a mieux.

Amegilla commented 5 years ago

Je ne trouve pas de date de saisie ou date de dernière modification pour les relevés dans occtax. Cette information n'est pas stockée ?

camillemonchicourt commented 5 years ago

De mémoire c'est stocké dans les tables verticales d'historisation (gn_commons.t_history_actions). Voir https://github.com/PnX-SI/GeoNature/issues/339 pour plus de détails.

gildeluermoz commented 5 years ago

Oui ça existait mais comme ca faisait doublon avec l'historisation, on les a supprimées. Il faut avouer que ce n'est pas très facile à lire. Je pense que si tu en as un usage fréquent, il peut être judicieux de faire une vue qui te remonte ces infos.

camillemonchicourt commented 5 years ago

Oui. Par contre, je suis pas hyper favorable à trier par défaut sur la date de création. Déjà car c'est pas lisible de trier sur un champs qui n'est pas affiché dans la liste.

Et car quand on arrive sur le module, on est intéressé par un tri par date d'observation, la date de création est une info technique.

Amegilla commented 5 years ago

Ok, je n'ai pas pensé à regarder ce coté là merci. Donc si je veux récupérer la date de dernière modification d'un relevé, il faut que je fasse un UNNEST du champ table_content ?

Là c'est plus du paramétrage donc pas besoin d'imposer cette config à tout le monde. J'ajouterai bien sur le champ date de saisie pour la compréhension du tableau.

gildeluermoz commented 5 years ago

table_content contient, en JSON, l'observation elle même. Si tu veux la date de la dernière modification, tu fais un max sur operation_date where operation_type = 'UPDATE' (NEW pour la création) et tu fais un JOIN entre l'uuid sinp de occtax.cor_counting_occtax et uuid_attached_row de gn_commons.t_history_actions. Si besoin tu peux faire un JOIN sur le champ uuid_sinp de la synthese. A terme, on doit mettre à jour tout ça pour utiliser un uuid interne à GN2 car l'uuid sinp n'est pas forcement disponible.

Amegilla commented 5 years ago

Merci pour les explications. Je n'avais pas compris que l'uuid 'uuid_attached_row' dans la table t_history_actions pouvait être utilisé comme ça. Du coup avec une requête de ce style, j'arrive bien à ce que je veux. J'ai plus qu'à intégrer cette info dans la vue du module occtax.

select o.id_releve_occtax, max(h.operation_date) from pr_occtax.t_releves_occtax o join gn_commons.t_history_actions h on o.unique_id_sinp_grp = h.uuid_attached_row group by o.id_releve_occtax;

camillemonchicourt commented 5 years ago

On a mélangé 2 sujets dans un même ticket.

Dans ton cas, si tu veux classer les relevés par date de saisie, en effet c'est plutôt sur l'objet t_releves_occtax que tu vas chercher la date (id_table_location=6). Et plutôt sur l'action I (insert), ou sur les actions I et U (update) si tu veux qu'à chaque modification le relevé remonte en haut de la liste.

Par contre je ne suis pas sur que si on modifie un taxon ou un dénombrement d'un relevé, cela modifie la date d'update du relevé.

Amegilla commented 5 years ago

Effectivement il va me manquer la partie qui concerne les taxons. C'est d'ailleurs sans doute plus intéressant de regarder la dernière date d'action sur la table t_occurrences_occtax plutôt que t_releves_occtax en attendant de trouver une solution pour coupler les deux.

camillemonchicourt commented 4 years ago

Refonte complète du module Occtax dans la version 2.5.0. Reste en suspens la question de l'ordre des taxons dans la liste des taxons d'un relevé : https://github.com/PnX-SI/GeoNature/issues/682

PnX-SI / GeoNature

Occtax : Optimiser la lecture des occurrences déja saisies dans un relevé #635