Développement #50145
Inscriptions récurrentes
0%
Description
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é de ResizeBooking.
Files
Related issues
History
Updated by Valentin Deniaud almost 4 years ago
- File 0002-manager-create-event-recurrences-when-end-date-is-sp.patch added
- File 0003-api-allow-booking-all-recurrences-of-one-event-at-on.patch 0003-api-allow-booking-all-recurrences-of-one-event-at-on.patch added
- File 0001-agendas-add-event-recurrence-end-date-50145.patch added
- Status changed from Nouveau to Solution proposée
- Patch proposed changed from No to Yes
Première version minimale.
Dans 0003, je me retrouve à devoir créer beaucoup de bookings d'un coup (surprise). Du coup recours à bulk_create, sauf que Booking.save() mets à jour event.full, alors il faut réussir en une seule requête à faire la même opération sur tous les évènements concernés d'un coup. Ça se fait bien, surtout en django2.
Par contre, il me faut dans cette opération une annotation avec le nombre de places restantes, classiquement posée par Event.annotate_queryset. Sauf qu'ensuite dans le calcul pour déterminer si l'évèment est complet, postgres m'a informé que je n'avais pas le droit d'utiliser ces annotations. Je les ai recodées en utilisant des Subquery et ça passe.
J'en viens à ma question, est-ce que je remplace Event.annotate_queryset avec ma version à base de Subquery ? Ça me paraît dangereux d'avoir ça fait de manières différentes à deux endroits, mais cette version est deux fois plus lente (j'ai testé avec différent jeux de données et ça a l'air d'être un vrai facteur 2, pas de trucs linéaires cachés quoi).
(à part ça d'autres trucs bof dans ce 0003 mais je laisse #41663 avancer avant de peaufiner)
Et démo postée sur le salon : https://perso.entrouvert.org/~vdeniaud/reccurring_events.ogv
Updated by Valentin Deniaud almost 4 years ago
- File deleted (
0001-agendas-add-event-recurrence-end-date-50145.patch)
Updated by Valentin Deniaud almost 4 years ago
- File deleted (
0002-manager-create-event-recurrences-when-end-date-is-sp.patch)
Updated by Valentin Deniaud almost 4 years ago
(je bouge l'ajout de la date de fin de récurrence vers #51218, afin de rendre ce ticket indépendant)
Updated by Frédéric Péters almost 4 years ago
- Related to Développement #49203: Événements récurrents added
Updated by Valentin Deniaud almost 4 years ago
- Status changed from Solution proposée to Information nécessaire
Pour l'instant j'ai imaginé pouvoir réserver toutes les récurrences d'un évènement, mais ça ne correspond pas au besoin, qui est de pouvoir vraiment dire, pour un évènement qui se répète tous les lundis et jeudis, « je réserve les premiers et troisièmes lundis du mois ».
Grande question préliminaire : comment wcs va exposer un tel choix, et plus précisément comment ça va se traduire au moment d'interroger chrono ?
Pour chrono le plus simple ça serait de recevoir l'id de l'évènement + une récurrence au format RRULE, est-ce que je pars sur cette idée ?
Updated by Valentin Deniaud over 3 years ago
- Status changed from Information nécessaire to Rejeté
À oublier, #54332.