[Synthese] - Proposition d'amélioration du tableau attributaire

[lepontois]

Bonjour la compagnie,

J'ai reçu hier un retour d'utilisation sur GeoNature qui soulève quelques souhaits d'évolution du tableau attributaire de la synthèse.

Pour certains besoins spécifiques, nous utilisons le champ commentaire (au niveau de l'observation) pour structurer des informations complémentaires n'ayant pas de champ adapté car hors du standard SINP. La demande est alors de pouvoir afficher ce champ dans le tableau attributaire pour pouvoir le lire en un clin d'oeil. Je pensais que c'était possible mais en regardant default_config.toml.example, j'ai compris que la liste des champs pouvant être ajouté se limite à quelques champs (id_synthese, date_min, cd_nom, lb_nom, nom_vern_or_lb_nom, st_asgeojson, observers, dataset_name, url_source).

Pour en venir à ma proposition, je pense qu'il serait bien que plus de champ puisse être ajouté à cette table attributaire et éventuellement sous deux formes paramétrable :

• les champs affichés par défaut (tel que c'est le cas aujourd'hui mais en élargissant la liste des champs activables)
• les champs pouvant être "ajoutés" par l'utilisateur

Pour cette seconde forme, j'imaginais que le principe de la table attributaire d'OccTax soit repris:

Est-ce une évolution qui vous semble envisageable ?

Concernant l'export, serait-ce envisageable que l'utilisateur puisse définir les champs qu'il souhaite extraire ? ex : par défaut tout y est (ou liste de champ définit en paramètre) et possibilité que l'utilisateur puisse en "décocher".

[camillemonchicourt]

Afficher le commentaire dans la liste c'est un peu risqué car ils peuvent être longs. On pourrait l'ajouter dans les champs utilisables dans le tableau et libre à chacun de le mettre dans la synthèse de son GeoNature. Mais il faut voir aussi si cela n'a pas des conséquences en terme de performances en alourdissant la vue utilisée pour la liste de Synthèse, que l'on cherche aussi à optimiser.

Même question de performances et de lisibilité sur le fait d'ajouter quelques infos en déroulant les objets directement dans la liste. A voir si (et combien) ça alourdit le chargement de la liste et les recherches dans la Synthèse.

Le système de déroulé serait certainement à revoir, car dans Occtax plusieurs personnes de l'enlever car il apportait de la confusion avec la fiche détails, dont des personnes passaient à côté, pensant que tout est dans l'accordéon déroulé.

Pour les exports dont le contenu serait personnalisé, à voir. Car le contenu des exports est déjà personnalisable au niveau de l'instance GeoNature, donc ça peut être complexe de proposer un choix des champs dynamiques. De mon côté, je trouve que c'est aussi un peu lourd au niveau UX, et je pensais plutôt à proposer 2 exports : un complet et un léger (avec juste les champs de base essentiels).

[camillemonchicourt]

Ah je me suis embrouillé... Tu parlais de la petite roue crantée pour choisir les champs affichés dans la liste Occtax. Moi je parlais de la possibilité de "dérouler" une ligne, pour en voir quelques infos complémentaires directement dans la liste...

[PNPyrenees]

Je suis bien d'accord pour le côté performance. Faut trouver le bon équilibre en faisant des tests. Plus on va en ajouter dans le tableau ou la roue crantés plus ça sera lourd.

Pareil pour l'export, je comprends que rendre possible la sélection des champs à extraire peut complexifier le code (et potentiellement l'interface) en rajoutant des conditions. Si l'uilisateur a tripoté la liste des champs alors ce sont les champs du select sinon ceux par défaut... Je me rend pas compte comment ça peut s'intégrer côté code. L'idée de deux types d'export (complet / léger) est une alternative intéressante à partir du moment ou les deux sont paramétrable dans les fichiers de configuration.