Créer un composant pour pouvoir faire du filtrage multiple

[bouviermullerp]

Pouvoir effectuer des filtres sur plusieurs types de données Il y a des composants React Admin qui permettent d'effectuer des filtres sur des attibuts, mais on ne peut en sélectionner qu'un seul. Nous avons besoin de développer un composant qui permette de sélectionner plusieurs attributs et filtrer sur ces données.

Prérequis avant chiffrage

• [ ] Titre de l'issue liée #

Issues liées

• [ ] Titre de l'issue liée #

Estimation du temps de travail en JH

• @srosset81:
• @simonLouvet:

[simonLouvet]

La problématique est double :

• Les composants d'interface react-admin de filtrage ne sont pas prévu pour pouvoir sélectionner plusieurs valeur dans une liste qui sert à un Filter. Il est nécessaire de créer un CutomFilter avancé avec selection multiple.
• Il est nécessaire d'inventer un langage pour aller au delà du filter habituel de React-Admin qui n'est prévu que pour une valeur par champ. Les composant de vue doivent paser un fliter (sous forme d'objet json) à l'adapter. Nous pourrions nous baser sur la logique de mongo mais c'est à arbitrer + faire les développement dans l'Adapter.

[srosset81]

Le premier point ne devrait pas poser de problème. Le second consiste essentiellement à modifier notre "semantic data provider" pour qu'il gère un array de filter. Plutôt que de gérer uniquement hasTheme: 'https://localhost/permaculture', il devra gérer hasTheme: ['https://localhost/permaculture', 'https://localhost/tiers-lieux']

[simonLouvet]

issue initiale pour passerelle : https://github.com/data-players/passerelle_normandie/issues/105

@srosset81 la question est justement de se mettre d'accord sur le formalisme que comprendra le dataAdapter. est ce que un erray se traduit en OU ou en ET? Est ce qu'il est préférable de definir un laguange de filtre plus avancé comme ce qui se fait sur mongo par ex: https://docs.mongodb.com/manual/reference/operator/query/and/ https://docs.mongodb.com/manual/reference/operator/query/or/

On voit ca en réunion technique à la rentrée?

[srosset81]

Pour le moment les filtres gérés par React-Admin sont en ET. Donc je serai pour garder ce fonctionnement avec les array. Et s'il y a besoin d'un OU, on peut voir pour utiliser un langage plus compliqué de type mongodb.

[srosset81]

Pour info React-Admin réfléchit à comment implémenter ce type de filtrage avancé dans la v4: https://github.com/marmelab/react-admin/issues/5933#issuecomment-829428150 S'il n'y a pas d'urgence à utiliser un filtrage en OU, je serai pour attendre de voir ce qui en sort.

[GuillaumeAV]

T'as une idée de pour quand ce sera la v4 @srosset81 ? Peut-être directement contribuer à React Admin ?

[srosset81]

Non aucune idée

[bouviermullerp]

Peut être qu'on peut créer une seconde issue pour le filtrage en OU ? Ce chantier est plutôt destiné à accueillir les spécifications pour du filtrage multiple (plusieurs critères de sélection).

Egalement, pour des filtrages, requêtes plus avancées, on pourra utiliser sparnatural (avant la fin d'année normalement).

[simonLouvet]

Le filtrage demandé par passerelle est justement un filtrage en OU. Je veux les data dont la propriété 1 est A ou B

[simonLouvet]

J'ai regardé la discussion https://github.com/marmelab/react-admin/issues/5933#issuecomment-829428150 et les filtres avancés n'ont pas l'aire encore arbitré. De plus, Il n'est question que de faire des valuer inferieurs ou superieurs et non pas des OU ou des ET. Je propose donc uns spécification.

Lors ce que nous voulons faire un filtre avancé :

filter=
{
   advanced-filter-type: <type>,
   advanced-filter-contnent : <filter>
}

cela pourrait donner

filter=
{
   advanced-filter-type: 'mongo',
   advanced-filter-contnent : { $or: [ { quantity: { $lt: 20 } }, { price: 10 } ] }
}

[bouviermullerp]

Merci pour la spec technique @simonLouvet , preneur d'une clarification sur les impacts fonctionnels, ce qui sera possible (et impossible).

[simonLouvet]

modificaiton de spec suit echange avec @srosset81

supoprt uniquement de $or, $and,$lt, $gt, $eq sur 2 niveu de profondeur. filter= { advancedFilter : { $or: [ { quantity: { $lt: 20 } }, { price: 10 } ] } }

[simonLouvet]

Le besoin pour le projet PETR Sub Bourgogne nécessite de faire une requête à un niveau plus profond que le premier niveau de propriété que les seul propriété de la classe principale intereogé. exemple du besoin:

• Les tiers lieux sont des organisations.
• Les tiers lieux dispose d'équipements
• les équipements ont un type d’équipement
• l'utilisateur doit pouvoir trouver les tiers lieux qui dispose d'un (ou plusieurs) type d’équipement

Evolution du besoin :

• conserver l'utilisation du queryparam filter nativ à react-admin avec mongo_where comme seul propriété

filter=
{
mongoWhere : {}
}

• pouvoir faire des filter avec au moins 1 niveau de profondeur à l'image de mongodb pour Query on Embedded Documents

{
   'petr:equipmentOffers':{
      'petr:hasEquipmentType':equipmentTypeUri
   }
}

• combiner ce besoin avec la spécification précédente (cas réel besoin PETR). $in, $or, $and doivent être supporté à tous le niveaux. $and pourrait être remplacé par $or dans le cas ci dessous.

{
      '$and' : [
         {
            'pair:organizationType' : {
               '$in' : [
                  organizationTypeUri1,
                  organizationTypeUri2
               ]
         },
         {
            'petr:equipmentOffers':{
               'petr:hasEquipmentType':{
                  $in :[
                     equipmentTypeUri1,
                     equipmentTypeUri2
                  ]
               } 
            }
         }
      ]
}

[simonLouvet]

@srosset81 est ce que la spécification ci dessus est assez precise?

[srosset81]

@simonLouvet Oui merci.

Je note que $in est ajouté en plus par rapport à la spec précédente. J'imagine que $neq aurait du sens aussi. Pas compliqué à faire une fois qu'on a $eq.

[simonLouvet]

@srosset81 j'ai rajouté $in car je pensais que $or suffirait mais ce n'est pas applicable à des valeurs finales. $neq pourrait être utile mais nous n'en avons pas encore rencontré le besoin. J'ai cherché une lib qui transformerai un mongo query en sparql mais j'ai pas trouvé.

[simonLouvet]

a réaliser après assemblee-virtuelle/semapps#892

[srosset81]

Je ne pense pas que ça concerne Archipelago car c'est un composant spécifique, qui sera utilisé principalement dans des projets spécifiques.

Je rebouge dans le repo SemApps.