Development #55367
api fillslots (réservation multiple), option pour créer des réservations indépendantes
0%
Description
Si on garde l'API fillslots (question dans #40395, important de se décider), il y aurait à prendre en compte cette remarque :
Le fonctionnement primary/secondary marche bien uniquement pour la partie "je me désinscris totalement", pour les autres opérations on voudrait plutôt des événements indépendants.
Si on veut juste répondre à ça, on pourrait ajouter un paramètre supplémentaire à l'appel, pour dire de ne pas créer de secondary. Ça amène les questions sur le retour de l'appel, retourner une liste avec la réponse détaillée pour chaque réservation ? (par réponse détaillée j'entends notamment la série "api": {"cancel_url": ...
.
Fichiers
Révisions associées
api: move event selection code to function (#55367)
api: add endpoint to book multiple events independently (#55367)
api: rename recurring events views (#55367)
Historique
Mis à jour par Valentin Deniaud il y a plus de 2 ans
Comment on gère si dans la réservation de ['a', 'b', 'c'], 'b' est full ? On arrête tout ? (je dirais que oui, c'est d'ailleurs le cas actuellement, mais comme je pars sur une nouvelle API tout est possible)
Mis à jour par Thomas Noël il y a plus de 2 ans
Pour l'instant je pense qu'on peut partir sur un blocage dès que quelque chose est full, donc un retour err:1 et une explication de ce qui est full (autant que possible). Ça sera plus facile à gérer en retour de l'appel dans le workflow.
(Quitte à plus tard imaginer un flag "reserve-ce-qui-est-possible" si c'est nécessaire)
Mis à jour par Valentin Deniaud il y a plus de 2 ans
- Fichier 0001-api-rely-on-DRF-validation-55367.patch 0001-api-rely-on-DRF-validation-55367.patch ajouté
- Fichier 0003-api-add-endpoint-to-book-multiple-events-independent.patch 0003-api-add-endpoint-to-book-multiple-events-independent.patch ajouté
- Fichier 0002-api-move-event-selection-code-to-function-55367.patch 0002-api-move-event-selection-code-to-function-55367.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Thomas Noël il y a plus de 2 ans
0001: au niveau des tests, vérifier que les réponses ne sont pas trop modifiées, genre « assert resp.json['reason'] == 'slots list cannot be empty' # legacy
» est certainement là parce qu'on a encore des workflows qui testent cette réponse.
0002: ok
0003: il faudrait au moins, dans la réponse pouvoir dire si des résa ont été prises sur des listes d'attente (si on peut détailler slot par slot c'est bien mais bon)
Mis à jour par Valentin Deniaud il y a plus de 2 ans
- Fichier 0001-api-rely-on-DRF-validation-55367.patch 0001-api-rely-on-DRF-validation-55367.patch ajouté
- Fichier 0003-api-add-endpoint-to-book-multiple-events-independent.patch 0003-api-add-endpoint-to-book-multiple-events-independent.patch ajouté
- Fichier 0002-api-move-event-selection-code-to-function-55367.patch 0002-api-move-event-selection-code-to-function-55367.patch ajouté
Thomas Noël a écrit :
0001: au niveau des tests, vérifier que les réponses ne sont pas trop modifiées, genre «
assert resp.json['reason'] == 'slots list cannot be empty' # legacy
» est certainement là parce qu'on a encore des workflows qui testent cette réponse.
Je garde la modification du message parce que je doute qu'un workflow qui regarde ça existe (spécifique résa multiple + cas limite) mais j'ajoute le check de 'reason' pour la beauté du diff.
0003: il faudrait au moins, dans la réponse pouvoir dire si des résa ont été prises sur des listes d'attente (si on peut détailler slot par slot c'est bien mais bon)
OK j'ai ajouté la liste des évènements pour lesquelles la résa a été prise sur liste d'attente dans la réponse.
Mis à jour par Thomas Noël il y a plus de 2 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Valentin Deniaud il y a plus de 2 ans
- Fichier 0001-rename.patch 0001-rename.patch ajouté
- Statut changé de Solution validée à Solution proposée
À l'oral tu m'avais dit ne pas aimer l'URL /event_fillslots/, qu'est-ce que tu dirais d'un renommage au profit de /events/fillslots/, avec events qui fait référence au kind=events
des agendas concernés ?
Mis à jour par Frédéric Péters il y a plus de 2 ans
Perso je n'aime vraiment pas les underscores dans les url mais vu qu'il y en a déjà qui se sont glissées dans recurrent_fillslots/_events, je dirais de laisser ainsi, et qu'on réfléchisse peut-être plus tard à comment réorganiser.
Mis à jour par Valentin Deniaud il y a plus de 2 ans
Frédéric Péters a écrit :
vu qu'il y en a déjà qui se sont glissées dans recurrent_fillslots
(vue pour le moment désactivée par défaut et utilisée nulle part)
je dirais de laisser ainsi, et qu'on réfléchisse peut-être plus tard à comment réorganiser.
L'avantage à voir ça maintenant ce serait de ne pas avoir d'URL « legacy » à supporter.
Mis à jour par Frédéric Péters il y a plus de 2 ans
Ok si les autres ne sont à coup sûr nulle part utilisées, voyons ça maintenant.
D'un premier jet j'aurais comme proposition :
- agenda/(?P<agenda_identifier>[\w-]+)/events/fillslots/ (ton patch rename)
- agenda/(?P<agenda_identifier>[\w-]+)/recurring-events/ (views.recurring_events_list)
- agenda/(?P<agenda_identifier>[\w-]+)/recurring-events/fillslots/
ça m'ennuie d'alors ne pas avoir un events/ qui serait un views.events_list mais on peut se dire que ça s'ajouterait facilement plus tard.
Mis à jour par Valentin Deniaud il y a plus de 2 ans
- Fichier 0004-api-rename-recurring-events-views-55367.patch 0004-api-rename-recurring-events-views-55367.patch ajouté
- Fichier 0003-api-add-endpoint-to-book-multiple-events-independent.patch 0003-api-add-endpoint-to-book-multiple-events-independent.patch ajouté
Voilà j'ai squashé mon rename dans 0003 et ajouté un 0004 pour renommer les autres endpoints.
Mis à jour par Lauréline Guérin il y a plus de 2 ans
- Statut changé de Solution proposée à Solution validée
ça manque un peu de test à mon goût (genre vérifier qu'on a une 404 si mauvais kind ou mauvais id, book past/future, etc), mais j'ai tendance à en écrire beaucoup ... :)
Mis à jour par Valentin Deniaud il y a plus de 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit ec53b37d2d022e3fba14495b122f40c2a65a112b Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Tue Aug 3 14:02:10 2021 +0200 api: rename recurring events views (#55367) commit a26183e5faa3ae57d9a2062b5e218c5f6f224d88 Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Thu Jul 29 11:20:38 2021 +0200 api: add endpoint to book multiple events independently (#55367) commit 3936f9450a03558a03ae264087fe867f0ac47898 Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Thu Jul 29 11:20:38 2021 +0200 api: move event selection code to function (#55367) commit 63c7dfecc11f030b2bfc38e9849a8aeb4bb86c2c Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Thu Jul 29 11:19:58 2021 +0200 api: rely on DRF validation (#55367)
Mis à jour par Valentin Deniaud il y a plus de 2 ans
Lauréline Guerin a écrit :
vérifier qu'on a une 404 si mauvais kind ou mauvais id, book past/future
(poussé en ajoutant ces deux là)
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
api: rely on DRF validation (#55367)