Open bouttier opened 2 weeks ago
La piste privilégié consiste à rajouter dans taxref le chemin complet dans l’arbre taxonomique pour tous les taxons comme décrit ici : PnX-SI/TaxHub#354 Le filtrage est alors immédiat. Il semble très pertinent de finaliser cette fonctionnalité avant de rajouter les filtres taxonomiques.
Oui, cela semble nécessaire de finaliser la fonctionnalité en question si sa performance a pu être confirmée. Sur la branche feat/sinp,
c'est la fonction Postgresl find_all_taxon_children()
qui est utilisé et ce n'est pas assez performant.
Une autre piste pour améliorer les performance de filtre serait d'utiliser les valeurs des colonnes regne
, phylum
, classe,
ordre
, famille
, sous_famille
, tribu
, groupe1_inpn
, groupe2_inpn
et/ou groupe3_inpn
.
En effet, je pense qu'il y a très peu de demande de permissions avec un filtre taxonomique au niveau du rang "genre" ou inférieur. Nous pourrions donc peut être nous en passer.
Ceci dit cette solution est plus restrictive et demande surement à dénormaliser le modèle de la base de données...
ceci dit je ne suis pas très convaincu qu’il soit bien souvent utile de donner accès à plusieurs taxons lorsque l’on peut donner l’accès à une branche de l’arbre taxonomique ?
Oui, c'est bien le cas. Si un utilisateur sélectionne tous les enfants d'un nœud de l'arbre taxonomique, il faudrait automatiquement définir une seule permission en utilisant le nœud.
Ceci dit, ce n'est surement pas simple à mettre en place. Par ailleurs, je pense que dans la majorité des cas, les utilisateurs se simplifient la vie en demandant des permissions sur un seul niveau taxonomique englobant leurs besoins, quand c'est possible.
Un problème par exemple, c'est la sélection des "invertébrés". A priori, cela demande la sélection de plusieurs taxons sauf si on utilise le champ groupe3_inpn
.
Il me semble que les filtres regne
, phylum
, classe
, ordre
, famille
, sous_famille
et tribu
sont équivalent à un filtre sur le bon cd_ref
, je me trompe ? Si c’est bien le cas, la différence serait donc de filtrer via un index ltree
vs un index textuel sur les colonnes en questions. Je dirais qu’implémenter des filtres spécifiques pour ces colonnes ne serait à faire que si ltree
ne suffit pas en terme de performance (donc à tester en premier lieu).
Les filtres sur les groupes INPN sont assez intéressants pour plusieurs raisons :
cd_ref
cd_ref
cd_ref
(mais vérifier les perfs de ltree
sur une liste de taxons, qui, si elles sont suffisantes, peuvent permettre de s’affranchir d’une spécificité groupes INPN)À réfléchir comment les filtres de groupes INPN s’articulent avec les filtres taxonomiques. Peut-être deux types de filtres distincts ?
Il est souhaité de rajouter aux permissions un filtre taxonomique permettant de restreindre une permission à certains taxons uniquement (https://github.com/PnX-SI/GeoNature/issues/3097).
On souhaite pouvoir donner l’accès à plusieurs taxons, qui ne sont pas nécessairement des espèces (ceci dit je ne suis pas très convaincu qu’il soit bien souvent utile de donner accès à plusieurs taxons lorsque l’on peut donner l’accès à une branche de l’arbre taxonomique ?). Même remarque que pour les filtres géographiques, on préférera pouvoir associer plusieurs taxons à une permissions plutôt que de devoir créer plusieurs permissions distinctes.
Pour mettre en place ce filtre, il faut :
cor_permission_taxref
au schémagn_permissions
avec une colonne FK versgn_permissions.t_permissions.id_permission
et une colonne FK verstaxonomie.taxref.cd_ref
.taxons_filter
sur le modèlePermission
contenant la liste des taxons alloués par la permission.taxons_filter
dans la tablet_permissions_available
Permission.filters_fields
une entrée"TAXO": taxons_filter
.Permission.filters
de sorte qu’ellecontinue
lorsque la listetaxons_filter
est vide (cas d’un filtre de type liste non existant jusque là – tâche commune avec les filtres géographiques).PermFilter.__str__
pour l’affichage de la permission dans l’interface d’admin :PermissionAdmin
etPermissionAvailableAdmin
et notamment lefilters_formatter
Pour prendre en compte le filtre dans la synthèse, il faut l’implémenter deux fois :
get_one_synthese
get_observations_for_web
Puis il faut passer la colonnetaxons_filter
àTRUE
dans la tablet_permissions_available
pour le R (et le E) de la synthèse.Pour la vérification unitaire, à implémenter dans
Synthese._has_permission_grant
:TAXO
àif perm.has_other_filters_than(...)
if perm.taxons_filter:
vérifiant si l’observation appartient à une partie autorisé de l’arbre taxonomique. Il faut probablement interroger la vue d’union récursive des taxons parcd_sup
.Pour le filtrage d’une liste d’observation, à implémenter dans
SyntheseQuery.build_permissions_filter
:TAXO
àif perm.has_other_filters_than(...)
if perm.taxons_filter:
Toute la difficulté de l’implémentation de ses filtres réside dans la détermination de l’ensemble des observations concernés par un filtre taxonomique alors que celui-ci porte sur une branche de l’arbre taxonomique.
Ce problème se pose de manière identique pour les règles de sensibilité, celle-ci pouvant porter également sur une branche de l’arbre taxonomique. La solution apporté pour la sensibilité consiste à dupliquer les règles de sensibilité pour chaque ramification de la branche sur laquelle porte la règle original. Ceci est effectué au moyen d’une vue matérialisé récursive sur le
cd_sub
: https://github.com/PnX-SI/GeoNature/blob/8fae7270d75362c2292fe54be5258c6366b208ea/backend/geonature/migrations/data/core/sensitivity.sql#L108-L129 Cependant, il apparaît peu opportun de dupliquer les permissions de la même manière (problème de performance, qui a d’ailleurs déjà pu être constaté lors de la duplication des règles pour les membres des groupes).La piste privilégié consiste à rajouter dans taxref le chemin complet dans l’arbre taxonomique pour tous les taxons comme décrit ici : https://github.com/PnX-SI/TaxHub/issues/354 Le filtrage est alors immédiat. Il semble très pertinent de finaliser cette fonctionnalité avant de rajouter les filtres taxonomiques. Il reste toutefois possible de mettre en place les filtres taxonomiques sans attendre en effectuant des requêtes
WITH RECURSIVE
, mais avec certainement de très mauvaise performance, notamment pour le filtrage de la synthèse.