Projet

Général

Profil

Development #50145

Inscriptions récurrentes

Ajouté par Valentin Deniaud il y a plus de 3 ans. Mis à jour il y a plus de 2 ans.

Statut:
Rejeté
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
14 janvier 2021
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

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.


Fichiers


Demandes liées

Lié à Publik - Development #49203: Événements récurrentsFermé08 décembre 2020

Actions

Historique

#1

Mis à jour par Valentin Deniaud il y a environ 3 ans

  • Description mis à jour (diff)
#2

Mis à jour par Valentin Deniaud il y a environ 3 ans

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

Mis à jour par Valentin Deniaud il y a environ 3 ans

  • Fichier 0001-agendas-add-event-recurrence-end-date-50145.patch supprimé
#4

Mis à jour par Valentin Deniaud il y a environ 3 ans

  • Fichier 0002-manager-create-event-recurrences-when-end-date-is-sp.patch supprimé
#5

Mis à jour par Valentin Deniaud il y a environ 3 ans

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

#6

Mis à jour par Frédéric Péters il y a environ 3 ans

#7

Mis à jour par Valentin Deniaud il y a environ 3 ans

  • Statut changé de Solution proposée à 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

Mis à jour par Valentin Deniaud il y a presque 3 ans

  • Statut changé de Information nécessaire à Rejeté

À oublier, #54332.

#9

Mis à jour par Mikaël Ates il y a plus de 2 ans

  • Statut changé de Rejeté à Fermé
#10

Mis à jour par Mikaël Ates il y a plus de 2 ans

  • Statut changé de Fermé à Rejeté

Formats disponibles : Atom PDF