Project

General

Profile

Development #50145

Inscriptions récurrentes

Added by Valentin Deniaud 9 months ago. Updated 5 months ago.

Status:
Rejeté
Priority:
Normal
Category:
-
Target version:
-
Start date:
14 Jan 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

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

Related to Publik - Development #49203: Événements récurrentsNouveau08 Dec 2020

Actions

History

#1

Updated by Valentin Deniaud 9 months ago

  • Description updated (diff)
#2

Updated by Valentin Deniaud 9 months ago

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

#3

Updated by Valentin Deniaud 8 months ago

  • File deleted (0001-agendas-add-event-recurrence-end-date-50145.patch)
#4

Updated by Valentin Deniaud 8 months ago

  • File deleted (0002-manager-create-event-recurrences-when-end-date-is-sp.patch)
#5

Updated by Valentin Deniaud 8 months ago

(je bouge l'ajout de la date de fin de récurrence vers #51218, afin de rendre ce ticket indépendant)

#6

Updated by Frédéric Péters 8 months ago

#7

Updated by Valentin Deniaud 8 months 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 ?

#8

Updated by Valentin Deniaud 5 months ago

  • Status changed from Information nécessaire to Rejeté

À oublier, #54332.

Also available in: Atom PDF