Refactor api filters

[Keksoj]

Description

Les filtres comme paramètres individuels

Dans la continuité de la refonte de la pagination et du tri de l'api, ll semble évident d'harmoniser la gestion des paramètres de la requête envoyée par le front-end.

Les filltres sont jusqu'à présent reçus sous forme d'un tableau JSON stringifié :

{ title: 'Lead', datePosted_before: '2020-05-02' }

lui-même transporté dans la requête en tant que paramètre filters :

/api/job-postings?filters=%7B%22title%22%3A%22Lead%22%2C%22datePosted_before%22%3A2020-05-02%7D

Il s'agit d'extraire chaque filtre en tant que paramètre de requête à part entière. Des opérateurs sont associables à chaque filtre:

operateur	applicable à	explication
:eq	string, number, date	Is equal to
:gt	number, date	Is greater than
:lt	number, date	Is less than
:gte	number, date	Is greater than or equal to
:lte	number, date	Is less than or equal to
:%l%	string	%LIKE%
:l%	string	LIKE%
:%l	string	%LIKE

La syntaxe des opérateurs (optionnels) est la suivante : filtre(:opérateur)=valeur

Avec des opérateurs par défaut, par exemple %l% pour title, le tout documenté dans le contrat openAPI.

Notre requête devient:

/api/job-postings?title=Lead&datePosted:lt=2020-06-24

Related Issue

Closes #57

ToDo list:

• [x] Rédiger un ADR concernant cette nouvelle implémentation (pour l'historique. Ne pas hésiter à reprendre la présente issue)
• [x] Reprendre la gestion du filtres dans les router.s de job-posting et organization
• [x] Reprendre la gestion du filtres dans les repository de job-posting et organization
• [x] Mettre à jour la fonction d'assainissement de sanitizers
• [x] Mettre à jour le contrat OpenAPI
• [x] Mettre à jour les tests end-to-end
• [x] Mettre à jour le dataProvider de react-admin

[Keksoj]

Prêt pour relecture!

[Keksoj]

Merci beaucoup ! Concernant les opérateurs par défaut, je me suis dit gue pour title par exemple c'était évident d'avoir %LIKE% par défaut, et en continuant sur cette lancée j'ai cherché les opérateurs les plus intuitifs, sans savoir si ça faisait partie des bonnes pratiques pour une API. Je peux enlever TOUS les opérateurs par défaut et ce sera au front de faire le boulot. J'ai effectivement besion de retours là-dessus.

[Keksoj]

Okay les corrections sont faites, il fe reste plus qu'à décider des opérateurs par défaut. Pour rappel, les voilà tels qu'ils sont documentés dans le contrat :

job-postings

• title (%l%)
• skills (%l%)
• employmentType (eq)
• datePosted (eq)
• jobStartDate (eq)
• validThrough (lt)
• hiringOrganizationName (%l%)
• hiringOrganizationPostalCode (l%)
• hiringOrganizationAddressLocality (l%)
• hiringOrganizationAddressCountry (l%)

organizations

• name (%l%)
• addressLocality (l%)
• postalCode (l%)

[Keksoj]

Okay pour l'approche KISS je part là-dessus !