/allnamebylist/ attend un code_liste mais Occtax passe un id_liste...

[camillemonchicourt]

Depuis la version 1.8.0 de TaxHub, un code_liste a été ajouté à la table taxonomie.bib_listes : https://github.com/PnX-SI/TaxHub/blob/master/data/update1.7.3to1.8.0.sql

En même temps la route /allnamebylist/ a été modifiée pour prendre le code_liste en paramètre au lieu du id_liste (#223).

Mais Occtax, ou même Occtax-mobile continue à interroger un id_liste quand il appellent cette liste.

Cela peut causer des soucis si l'administrateur créé une nouvelle liste et lui attribue un code différent de l'ID, ce qui est censé être le cas avec 100% des listes nouvellement créées vu que l'on demande un code_liste à l'utilisateur et que la liste n'a pas encore d'ID_liste.

Jusqu'à présent ce n'est pas remonté car lors de l'ajout du champs code_liste celui-ci a été rempli avec les id_liste existants : https://github.com/PnX-SI/TaxHub/blob/master/data/update1.7.3to1.8.0.sql#L7

Exemple d'un retour d'un utilisateur qui a créé une liste de taxons en lui attribuant le code "orchids", mais quand Occtax interroge l'API de TaxHub il tape sur taxhub/api/taxref/allnamebylist/101?search_name=orchis&limit=20 qui renvoie logiquement une erreur 400, car il n'existe pas de liste de taxon avec le code_liste égal à 101.

On pourrait envisager que Occtax et Occtax-mobile appellent le code_liste plutôt que le id_liste, mais ça serait un peu tordu, et cela nécessiterait de stocker le code_liste au niveau de Occtax (dans la conf pour la liste globale ou dans la BDD pour les listes par JDD).

Il semble plutôt souhaitable de garder par défaut une interrogation par id_liste et d'avoir une option pour interroger par code_liste, non ?

[mvergez]

Salut Camille,
Je tombe sur cette issue qui semble en lien avec celle ci : PnX-SI/GeoNature-citizen#327, où tu proposes :

qu'il ne devrait pas y avoir de route /allnamebylist/ comme actuellement.
Selon moi il devrait juste y avoir une route /names/ plus générique filtrable par id_liste, code_liste, rang taxonomique, cd_ref, etc...

Penses-tu que cela répondrait aussi à la problématique de cette issue ?

[camillemonchicourt]

Actuellement, il n'y a pas de soucis pour utiliser la route /allnamebylist/ au niveau de GeoNature-citizen et de la filtrer par code_liste, pour pouvoir y proposer des programmes avec des listes de taxons auto-complétées, non limitées à 100 taxons.

Mais en passant, je faisais une remarque plus générale et prospective pour indiquer que selon moi, on devrait avoir une liste générique names au niveau de TaxHub, plutôt qu'une liste spécifique /allnamebylist/.
Mais cela me semble pas forcément conditionné.

[camillemonchicourt]

Finalement, on n'a pas créé une route /names qui semblait peu lisible, mais plutôt enrichi la route /taxref en y ajoutant une propriété listes, la possibilité de la filtrer sur un id_liste ainsi que de limiter les champs renvoyés : #451

api/taxref?fields=cd_nom,listes
api/taxref?id_liste=100
api/taxref?id_liste=100,5002&fields=cd_nom,listes

La table /taxref remplace ainsi la route /cor_nom_liste récemment créée mais qui était peu classique ni standard.

[camillemonchicourt]

Dans la 1.13.1, La route /allnamebylist prend comme paramètre id_liste et non plus le code_liste (qui peut toujours être utilisé en tant que paramètre get) pour corriger le soucis de filtre de taxons par liste dans GeoNature