Development #61669
API pointant vers une fiche particulière, mais avec filtre de vue personnalisée
0%
Description
Aujourd'hui on a /api/cards/<carddef-slug>/<card-id>; ce ticket pour avoir /api/cards/<carddef-slug>/<custom-view>/<card-id>, qui retournerait l'id s'il correspond aux critères de la vue uniquement.
L'origine est #58878 pour avoir une cellule "contenu d'une fiche" qui n'afficherait pas le contenu si pas dans la vue.
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a environ 2 ans
- Lié à Development #58878: "contenu d'une fiche", pouvoir restreindre la visibilité de la cellule selon l'appartenance de l'usager connecté à une fonction de la fiche ajouté
Mis à jour par Frédéric Péters il y a environ 2 ans
- Fichier 0001-api-add-endpoint-to-get-card-data-only-if-matching-c.patch 0001-api-add-endpoint-to-get-card-data-only-if-matching-c.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Il y a deux parties, dans wcs/forms/common.py, quand une vue personnalisée a été passée on regarde les id qui sont dedans et si jamais ça ne correspond pas à l'id demandé, hop 404. À écrire, ça, surtout le from wcs.backoffice.management import FormDefUI, FormPage, je me suis dit qu'il y aurait un moment proche de nettoyage de management.py, a priori pour isoler la partie sur la gestion des filtres dans une classe parente mais je n'ai pas regardé plus que ça, ça viendra une fois qu'on aura intégré tous les travaux actuels autour des filtres (opérateurs etc.).
L'autre partie dans wcs/api.py, la structure des URL actuelles est assez galère je trouve, avec le slug de la vue perso qui vient se caler derrière (list, ods, ou geojson), je revois ça pour notamment permettre de manière sûre et systématique un / final. Aussi j'introduis /api/cards/<carddef-slug>/<custom-view>/list, équivalent à /api/cards/<carddef-slug>/list/<custom-view>, ce qui sonne mieux pour ce qui était in fine l'objet de ce ticket, permettre /api/cards/<carddef-slug>/<custom-view>/<optional-card-id>/.
(c'est objectivement encore un peu moche ce _q_traverse).
Mis à jour par Lauréline Guérin il y a environ 2 ans
Si on s'amuse à passer des filtres à l'url (genre /api/cards/<carddef-slug>/<custom view>/<optional card id>/?filter-foo=bar), est-ce que ce filtre est pris en compte ?
C'est le cas lorsqu'on liste les formdata d'une custom view, les filtres additionnels sont pris en compte.
Mis à jour par Frédéric Péters il y a environ 2 ans
Oui c'est pris en compte. (j'ai rien fait pour mais via combo ça passe ?filter-user-uuid= et il est considéré).
(je peux ajouter un test pour valider ça)
Mis à jour par Lauréline Guérin il y a environ 2 ans
via combo ça passe ?filter-user-uuid= et il est considéré
C'est pas faux, c'est le but de la manoeuvre.
Ok pour un test :)
Mis à jour par Frédéric Péters il y a environ 2 ans
- Fichier 0001-api-add-endpoint-to-get-card-data-only-if-matching-c.patch 0001-api-add-endpoint-to-get-card-data-only-if-matching-c.patch ajouté
Voilà avec test ajouté qui ajoute ?filter-foobar=FOO et hop plus de résultat.
Mis à jour par Lauréline Guérin il y a environ 2 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Frédéric Péters il y a environ 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 8e76e7ba39f183baf2db4bb1bb2fad4de00bdd18
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Thu Feb 10 19:56:38 2022 +0100
api: add endpoint to get card data only if matching custom view (#61669)
Mis à jour par Transition automatique il y a environ 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
api: add endpoint to get card data only if matching custom view (#61669)