Closed edelclaux closed 1 month ago
camillemonchicourt
commented
2 months ago Si l'on désactive les infos sur les observateurs car on ne veut pas partager ces infos personnelles à tous les utilisateurs, il ne faut pas seulement les masquer côté Front-end, elles ne doivent aussi ne pas être accessibles niveau backend.
edelclaux
commented
2 months ago J'ai un peu survolé de la mise à disposition du contenu des différents onglets, elle sera traitée pour chaque onglet individuellement. Tu as raison d'étendre la portée de la config à l'app.
Je propose la gestion de la config de la fiche espèce pour ne pas la limiter au frontend. Pas contre, je ne sais pas quelle traduction choisir de "Fiche Espèce"
# [SPECIES_SHEET] ?
# [SPECIES_PAGE] ?
# [SPECIES_CARD] ?
[FICHE_ESPECE]
WITH_XXX = false # e.g WITH_OBSERVERS = falseSPECIES_SHEET
edelclaux
commented
2 months ago Ok, merci. J'attaque
camillemonchicourt
commented
1 month ago OK, merci pour ces compléments de l'analyse technique de ce sujet.
Qu'en est-il des Groupes INPN ? Souhaite-t-on les faire apparaître sur la fiche espèce ?
Oui, au même titre que les groupes taxonomiques, il sera important d'avoir les différents groupes INPN (1, 2 et 3) auquel appartient le taxon (dans un onglet "Taxonomie" un peu comme on a sur les fiches observations de la synthèse mais avec plus de détails ?). Et pour le picto principal, on s'appuiera surement sur un des groupes (2 comme GN-atlas ?) car ils sont pas mal pour rapidement comprendre de quel type d'espèce il s'agit.
Dans les profils, il y avait les indicateurs suivant: sont-ils à intégrer également à la fiche espèce ?
- Première observation
- Dernière observation
- Plage altitude
Il faut les remettre dans les profils en effet en l'état. Certainement en précisant ce que sont les profils et en redisant que les infos dans les profils s'appuient uniquement sur les données valides.
Et les remettre globalement au niveau de la fiche. Mais là les chiffres seront potentiellement différents car ils s'appuieront sur toutes les données, pas uniquement les valides.
Mais là ça soulève une grosse question sur les données des fiches espèces. Doit-on prendre en compte les permissions sur la Synthèse et donc aussi la portée.
Par contre les profils s'appliquent sur TOUTES les données, sans appliquer de filtres de permissions, et c'est logique aussi car sinon les profils perdent leur sens et raison d'être... Cela avait d'ailleurs posé quelques soucis car on avait potentiellement accès à des données sensibles dans les profils plus précises que ce qu'on peut voir par ailleurs dans la Synthèse... Je ne retrouve plus la discussions sur le sujet.
Qu'est-ce que signifie concrètement la prise en compte du floutage au niveau du calcul des statistiques ? Quelles informations sont sensibles ? Comment les masquer ?
Globalement il ne faut pas pouvoir accéder à des données sensibles plus précisément dans les fiches espèces que ce à quoi peut accéder par ailleurs dans la Synthèse. Mais comme ce sont des données synthétisées, je ne vois pas trop de cas. Sauf la carte des observations du taxons mais le sujet est traité ensuite et en s'appuyant sur la même route que la synthèse on aura donc les mêmes permissions et données comme tu le mentionnes. Mais par exemple dans les fiches observations de la Synthèse, si on a des permissions avec floutage, on n'affiche pas les zonages de taille inférieure au zonage de floutage dans la liste des zonages de l'observation. A garder en tête donc.
/synthese/taxon/stats/
-> area_type as parameter Est-ce que ça vous convient ?
Oui sur la forme, ça nous semble coller.
Mais plutôt /synthese/taxon/stats/cd_ref/
Sur cd_ref car il faut agréger les calculs sur toutes les observations des synonymes d'un même taxon. Et bien penser à agréger les éventuelles observations sur les taxons inférieurs...
Cette route pourrait renvoyer ces propriétés :
fields)fields et limité à des types de zonages si spécifiés avec des CODE_AREA_TYPE dans un paramètre area_types)/synthese/for_web/
Cette approche permet notamment la prise en compte transparente du floutage. Quelle est la vision de cette route ? Est-ce que c'est un socle sur lequel s'appuyer, ou il y a une envie de désengorger la méthode ? Est-ce que ça vous convient ?
Oui comme évoqué c'est très bien d'utiliser la même route qu'ailleurs pour la cohérence, les permissions, le floutage, etc... On aura donc aussi une éventuelle portée qui s'applique, mais c'est cohérent au regard de ce qui est évoqué plus haut. Pour la route, elle a un nom et une construction que l'on aimerait revoir pour être plus REST, plus standard et ne plus parler de "for_web", mais c'est un sujet plus global de reprise de l'API de GeoNature pour la rendre utilisable à l'extérieur de GeoNature. Et donc si on la renomme et la revois au niveau de la Synthèse, on le répliquera ici aussi.
La, c'est simple, on bouge tout l'actuel dans l'onglet profil Est-ce que ça vous convient ?
Oui il faudra peut-être en profiter pour caler quelques éléments de vocabulaire. Par exemple parler de "valide" partout (première observation valide, plage d'altitude valide...) et mettre une petite phrase de contexte plus clair.
Et dans le détail WITH_OBSERVERS ne nous plait pas trop comme nom de paramètre, mais on en recausera, c'est un détail.
Mais pour ces paramètres, il faudra bien réfléchir pour que ça masque l'onglet, mais aussi l'API, donc peut-être à affiner car le fonctionnement niveau API ne sera peut-être pas homogène si c'est pour les observateurs, pour la carte des observations, les profils, etc...
edelclaux
commented
1 month ago Merci pour ces réponses !
Je rajoute les informations sur le picto principal dans l'issue dédiée.
Je note l'apparition de l'onglet "Taxonomie" :)
Je vais créer une un élément du board dédié à l'affichage des informations de taxonomie + statuts.
Ok, merci pour les confirmations. Aucun soucis pour modifier les textes.
Ok pour ajouter les mêmes que la fiche espèce. On aura donc:
| Synthese | Fiche Espèce |
|---|---|
| R | R |
| R1 ou R2 | R vs Rorganismes |
Sur le point R vs Rorganismes, comment on tranche ?
Profiles: on ne touche pas au calcul actuel
Ok, merci pour les précisions.
Tout à fait! Je me suis trompé dans mon message..
A propos --> quel est la bonne pratique pour récupérer, à partir d'un cd_ref, les taxon inférieurs de manière récursive ? \ Vous avez un exemple quelques part ?
Pas de soucis, quand vous en trouvez un cool, on le change :)
edelclaux
commented
1 month ago Ce serait une bonne idée "Période d'obseration" au lieu de "Première" et "Dernière" ?
edelclaux
commented
1 month ago Je suis pas sur de savoir comment interpréter les yeux tex avery..
camillemonchicourt
commented
1 month ago Que je réfléchis. 🤣
DonovanMaillard
commented
1 month ago Que je réfléchis. 🤣
Tu sais faire ça?!
Padon... @edelclaux pour moi le terme période renvoie à la période de l'année, surtout sur les profiles et fiches espèces où on aborde plus ou moins les questions de phénologies. En plus, ces infos là permettent de voir un peu ce qu'on a dans la base mais c'est pas des infos qui concernent l'espèce (c'est pas ses dates d'apparition/disparition etc, c'est juste la connaissance qu'on en a). Parler des "bornes", des "premières/dernières observations" etc oui. Période je suis plus dubitatif.
DonovanMaillard
commented
1 month ago Pour les questions de données sensibles. Effectivement il ne faut pas que les profils et les fiches espèces "trahissent" la localisation des données qui sont floutées par ailleurs. On peut imaginer un paramètre pour simplement ne pas calculer/servir de fiche espèce et de profil pour les données qui sont sensibles, ou simplement ignorer les données avec une nomenclature "sensible" en synthèse.
Pour les permissions, le plus logique à mon avis est que chacun ait des infos qui collent aux données auxquel il a accès. Si on a choisi que untel ne peut pas lire les données dans le module synthèse, alors il ne doit pas pouvoir les lire ou les déduire ailleurs, tant que c'est faisable/pas usine à gaz...
camillemonchicourt
commented
1 month ago Ouais voilà, pour le terme "période" je réfléchissais à ce que tu expliques justement @DonovanMaillard. 😘 J'aimais bien l'idée de regrouper, raccourcir et simplifier mais ça peut apporter de la confusion la notion de "période". On est d'accord.
camillemonchicourt
commented
1 month ago On peut imaginer un paramètre pour simplement ne pas calculer/servir de fiche espèce et de profil pour les données qui sont sensibles, ou simplement ignorer les données avec une nomenclature "sensible" en synthèse.
Pour les données sensibles, je ne pense pas que cela soit une histoire de paramètres ou d'ignorer toutes les données sensibles. Quand on compte le nombre d'observations d'une espèce, même si l'utilisateur a un floutage de données sensibles, pas de raison de les lui exclure de ces calculs. Idem pour les observations de l'espèce par mois, etc... C'est juste au niveau carto qu'il faut être cohérent avec ce à quoi il a accès dans le module Synthèse. Donc utiliser la même route est idéal. Il y a juste les profils, où la carto peut permettre d'avoir une localisation plus précise que à quoi il a droit dans la Synthèse... Donc éventuellement, masquer la carto des profils si l'utilisateur est censé avoir les observations floutées pour cet espèce. 🤔
gildeluermoz
commented
1 month ago Je partage le point de vue de Camille et d'une manière générale, il faut se poser la question de la pertinence/cohérence et de l'usage des profils pour des personnes qui n'ont pas accès à l'ensemble des données de la base.
jpm-cbna
commented
1 month ago Il y a juste les profils, où la carto peut permettre d'avoir une localisation plus précise que à quoi il a droit dans la Synthèse... Donc éventuellement, masquer la carto des profils si l'utilisateur est censé avoir les observations floutées pour cet espèce. 🤔
Sur la branche feat/sinp, effectivement, la carto des profils ne prend pas en compte les données sensibles. Par contre, il faut également masquer dans l'onglet Zonage, les zonages trop précis vis à vis du niveau de floutage de l'observation. C'est l'objectif du champ size_hierarchy de la table ref_geo.bib_areas_types. Je ne sais pas si cela a été pris en compte dans l'onglet Zonage sur la branche master ?
camillemonchicourt
commented
1 month ago @jpm-cbna, il me semble que tu parles de l'onglet "Validation" sur les fiches des observations de la Synthèse. Le sujet ici sont les fiches espèces par taxons qu'elles prévoient de faire évoluer.
Dans la fiche d'une observation, si celle-ci est sensible et que l'utilisateur ne peut la voir que floutée, alors en effet, on n'affiche pas les zonages inférieurs au zonage de floutage : https://github.com/PnX-SI/GeoNature/blob/master/docs/CHANGELOG.md?plain=1#L89
Pour la carto des profils, si l'espèce est sensible et que l'utilisateur ne peut voir certaines observations que floutées, alors il faut masquer toute la carte plutôt que de l'afficher avec des données partielles, ce qui serait faux par rapport au concept de Profil.
jpm-cbna
commented
1 month ago @jpm-cbna, il me semble que tu parles de l'onglet "Validation" sur les fiches des observations de la Synthèse. Le sujet ici sont les fiches espèces par taxons qu'elles prévoient de faire évoluer.
Exact ! Du coup, vous pouvez ignorer mon retour. Merci, d'avoir confirmer que le floutage était bien pris en compte au niveau de la fiche d'une observation de la Synthese.
Epic: "Fiche espèce" #2981
Les derniers éclaircissements ont amené à ajuster un peu les tâches sur le développement de la fiche espèce. Il s'agit ici de maintenant ici de mettre en place non seulement le design, mais aussi la version MVP de la fiche espèce.
Cette dernière doit comprendre à minima:
Design
Le design sera conforme à la version précédente de cette issue (décrite ci-dessous), à laquelle sont intégrés les retours de Camille dans la discussion autour de cette issue
Propriétés
Les status, picto, le rang taxonomique, etc. seront traités par la suite, dans un espace de travail dédié.
Indicateurs
Les indicateurs affichés actuellement sont définis pour la validation, sur les plans techniques et métiers.
Contenu
Actuellement, ce sont des indicateurs liés à la validation.
Nous avons considéré les indicateurs suivants:
Floutage
Format de la route
Nous suggérons que la route utilisée pour le calcul des indicateurs se forme comme suivant:
/synthese/taxon/stats/<cd_nom>-> area_type as parameter
Carte des observations
Même comportement que la synthèse --> Le plus simple ici est l'utilisation de la route for_web, avec cd_ref en paramètre.
Cette approche permet notamment la prise en compte transparente du floutage.
Onglet Profile
La, c'est simple, on bouge tout l'actuel dans l'onglet profile
Version Précédente, design uniquement:
Travail sur le frontend de la fiche espèce. On souhaite ici conserver sensiblement le même contenu, en travaillant un peu plus les alignements, en ajustant les espaces, etc. S'appuyer sur la même stack que le reste de GN. Ajouter une pile d'onglets avec un mécanisme d'activation ou nom des onglets via la config. Cette nouvelle série d'entrée dans la config serait:
Il s'agit ici d'un travail portant uniquement sur le frontend. Les nouveaux éléments présents dans la capture d'écran ci-dessous (e.g nouveaux indicateurs) seront traités dans des issues séparées.