Development #50145
Mis à jour par Valentin Deniaud il y a plus de 3 ans
En se basant sur les évènements récurrents de #41663, on doit pouvoir s'inscrire en un coup à toutes les récurrences qui découlent d'un évènement récurrent.
/datetimes/ dans #41663 renvoie les récurrences et pas l'évènement récurrent, ici il faut permettre de faire l'inverse, c'est à dire renvoyer juste les évènements qui définissent des récurrences. Voir comment ça peut se traduire dans l'API, un paramètre en plus ou carrément un autre endpoint ?
Ensuite, dans /fillslot/, il faut comprendre qu'on a à faire à ce type d'évènement spécial et placer des bookings sur toutes ses récurrences. Actuellement ça coince parce que les récurrences sont lazy et créées au dernier moment. Ici, on veut qu'elles soient toutes en base, prêtes à être réservées. On va donc imposer qu'un évènement sur lequel on veut poser des réservations récurrentes ait une date de fin de récurrence (ça matche avec ce qui est attendu pour Publik Famille, les évènements sont récurrents sur un an). Ce qui va permettre de vraiment créer les récurrences au moment de la création/édition de l'évènement.
Et donc /fillslot/, il y a « juste » à poser un Booking pour chaque récurrence précédemment déduite. Rien à faire du côté du modèle Booking donc, la notion d'inscription récurrente n'apparaîtra finalement nulle part.
La suite, pour ce ticket ou un autre, c'est de permettre la visualisation et l'édition des réservations : annulation ponctuelle d'un jour, ou modification plus radicale (de mai à avril, je mange à la cantine le lundi et pas le mercredi).
J'imagine réutiliser les histoires de booking primaires et secondaires, dans l'affaire wcs ne va connaître que le booking primaire. Pour visualiser il faudra une API qui d'un booking primaire renvoie tous les secondaires. Et pour modifier, je verrai du côté côter de ResizeBooking.
/datetimes/ dans #41663 renvoie les récurrences et pas l'évènement récurrent, ici il faut permettre de faire l'inverse, c'est à dire renvoyer juste les évènements qui définissent des récurrences. Voir comment ça peut se traduire dans l'API, un paramètre en plus ou carrément un autre endpoint ?
Ensuite, dans /fillslot/, il faut comprendre qu'on a à faire à ce type d'évènement spécial et placer des bookings sur toutes ses récurrences. Actuellement ça coince parce que les récurrences sont lazy et créées au dernier moment. Ici, on veut qu'elles soient toutes en base, prêtes à être réservées. On va donc imposer qu'un évènement sur lequel on veut poser des réservations récurrentes ait une date de fin de récurrence (ça matche avec ce qui est attendu pour Publik Famille, les évènements sont récurrents sur un an). Ce qui va permettre de vraiment créer les récurrences au moment de la création/édition de l'évènement.
Et donc /fillslot/, il y a « juste » à poser un Booking pour chaque récurrence précédemment déduite. Rien à faire du côté du modèle Booking donc, la notion d'inscription récurrente n'apparaîtra finalement nulle part.
La suite, pour ce ticket ou un autre, c'est de permettre la visualisation et l'édition des réservations : annulation ponctuelle d'un jour, ou modification plus radicale (de mai à avril, je mange à la cantine le lundi et pas le mercredi).
J'imagine réutiliser les histoires de booking primaires et secondaires, dans l'affaire wcs ne va connaître que le booking primaire. Pour visualiser il faudra une API qui d'un booking primaire renvoie tous les secondaires. Et pour modifier, je verrai du côté côter de ResizeBooking.