api: allow getting all user bookings as ICS (#80685) #148
ecazenave
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "wip/80685-Reservation-multiple-avoir-une-A"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
458f6e6968to2afc459c1eWIP: api: allow getting all user bookings as ICS (#80685)to api: allow getting all user bookings as ICS (#80685)Par rapport au ticket initial il manque la partie : "Et que dans le retour à l'appel de réservation multiple on ajoute l'URL qui va bien (qui tape sur ce nouveau endpoint)."
On a ça nulle part en dehors du datetimes/fillslot lambda, c'est à la fois parce que les cas d'usage sont plus avancés, qu'on a pas d'identifiant à passer dans l'URL donc la simplification est moindre, et que l'API ne marche pas out of the box, il faut passer user_external_id.
Si aucun de ces arguments ne te convainc, je veux bien l'ajouter quand même :)
Je me disais juste dans events_fillslots, si est reçu un user_external_id (ça semble toujours le cas mais un blank=True dans le serializer me met un doute ), alors inclure dans la réponse le booking_ics_url ou whatever.
Dans la série "simplification" je trouverais ça vraiment bien d'avoir cet URL out of the box quand c'est possible plutôt que d'avoir à le constituer dans le workflow.
2afc459c1eto84a05d568984a05d5689to759fb018ccOuep tu as bien fait d'insister, au passage on gagne le filtre sur l'agenda courant, ce qui devrait éviter des situations inattendues.