Project

General

Profile

Développement #62635

Créer tous les évènements récurrents en base

Added by Valentin Deniaud over 2 years ago. Updated over 2 years ago.

Status:
Fermé
Priority:
Normal
Category:
-
Target version:
-
Start date:
10 March 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Les dernières évolutions Publik Famille font mauvais ménage avec le mécanisme d'ajout dynamique des évènements récurrents (je pense au patch de #62046 et 0003 de #62598).

Pour rappel, si un évènement récurrent a une date de fin (max 3 ans), on crée toutes ses récurrences en base.
Mais le champ n'étant pas obligatoire, si il n'en a pas, on crée les évènements au fur et à mesure qu'ils sont réservés. Pour permettre de réserver des évènements qui n'existent pas encore, on les fait apparaître dans le manager/les api comme si de rien n'était.

Cette fonctionnalité est utilisée en prod, mais à peu d'endroits (je peux faire un inventaire précis si besoin).

Il n'y a rien de vraiment ingérable mais on a quand même l'impression de produire du code pour rien : tous les évènements Publik Famille on une date de fin de récurrence, les patches relous sus-cités ne serviront jamais pour de vrai.

Deux solutions pour remédier à ça :
  • A. Rendre la date de fin obligatoire, le dire aux clients qui l'utilisent
  • B. Toujours permettre de ne pas mettre de date de fin, mais interdire la réservation postérieure à une année ou deux
    • Ça répond à l'objectif du ticket, on peut créer les évènements en base et virer l'ajout dynamique
    • Un help_text peut clairement documenter ce comportement
    • L'ajout au fil de l'eau des évènements pour qu'il y en ait toujours pour une année se ferait sans douleur, on a déjà un cron qui tourne toutes les 5 minutes pour mettre à jour les évènements

On part sur quoi ?


Files

Associated revisions

Revision ba38629a (diff)
Added by Valentin Deniaud over 2 years ago

agendas: always create event recurrences (#62635)

Revision 11fa0802 (diff)
Added by Valentin Deniaud over 2 years ago

agendas: stop adding event recurrences on the fly (#62635)

Revision d707c056 (diff)
Added by Valentin Deniaud over 2 years ago

agendas: remove code creating event recurrence on the fly (#62635)

Revision d6cf3306 (diff)
Added by Valentin Deniaud over 2 years ago

agendas: remove get_or_create_event_recurrence method (#62635)

Revision 7769ffab (diff)
Added by Valentin Deniaud over 2 years ago

agendas: simplify get_open_events method (#62635)

Revision b626b248 (diff)
Added by Valentin Deniaud over 2 years ago

agendas: remove useless subscription and shared custody code (#62635)

This includes partial revert of 56300815e7454bc1c364be7168a8de953de5dddd
and f158dc02ef04f497168ef8ac84d4c505c1274df8.

Revision 4f81c656 (diff)
Added by Valentin Deniaud over 2 years ago

agendas: always create event recurrences in update method (#62635)

History

#1

Updated by Lauréline Guérin over 2 years ago

  • Description updated (diff)

A: c'est sans doute la solution la plus facile (en terme de code) à mettre en place, mais pour les clients ça peut sans doute être contraignant: il faudra qu'ils modifient la date de fin d'année en année, ou recréent leurs events récurrents d'année en année.
Mais dans la vraie vie, est-ce qu'un event récurrent permanent existe vraiment ?

B: le plus souple pour les clients. Et on peut sans doute facilement limiter la réservation en appliquant un date_end automatique lorsqu'il n'est pas défini dans les endpoints datetimes et fillslots ?

Je penche pour la B.

#2

Updated by Emmanuel Cazenave over 2 years ago

B parait bien.

J'imagine qu;il faudra faire attention à des cas un peu chiants, genre un récurrent sans date de fin avec les évènements crées pour la deux ans à venir (avec le cron qui passe et qui ajoute au fur à mesure), et puis soudainement une date de fin qui apparaît pour dans 6 mois parce que ya plus de thunes pour l'atelier musique du lundi.

#3

Updated by Valentin Deniaud over 2 years ago

  • Description updated (diff)
#4

Updated by Valentin Deniaud over 2 years ago

J'ai découpé un max pour m'en sortir, je peux squash des choses si besoin.

0001: le patch annoncé, si pas de date de fin de récurrence tout se passe comme si il y en avait une à J+365.
0002: suppression du code qui ajoute les évènements à la volée. Ajout de la création des récurrences dans tous les tests qui testaient sans.
0003: suppression du code qui gère les faux évènements.
0004: dernière méthode à supprimer, plus utilisée seulement que dans les tests.
0005: simplification bonne à prendre de get_open_events.
0006: suppression du code devenu inutile introduit par les tickets cités en description.
0007: la récupération des évènements se basait sur l'exclusion des évènements déjà en db. C'est compliqué pour rien une fois que tout est en db. C'est plus simple de tenter de tout créer sans rien exclure, et se baser sur une contrainte d'unicité qui va refuser la création des évènements en double (tout est dans le ignore_conflicts=True).
0008: pour que la transition se fasse sans douleur, il faut s'assurer que les évènements actuellement présents sans date de fin soient créés au prochain passage du cron (il tourne toutes les 5 min, donc après la mise à jour il y aura ~5 min où éventuellement la réservation ne marchera pas, ça paraît acceptable). Ce patch bouge un peu de code pour que ça marche et ajoute un test.

#5

Updated by Lauréline Guérin over 2 years ago

0007: tu es sûr que l'ajout de la nouvelle contrainte d'unicité ne peut pas poser pb sur un env avec du legacy ?

#6

Updated by Valentin Deniaud over 2 years ago

Lauréline Guerin a écrit :

0007: tu es sûr que l'ajout de la nouvelle contrainte d'unicité ne peut pas poser pb sur un env avec du legacy ?

Oui mais ce patch pose d'autres questions au final, je le passerai dans un ticket à part. Branche à jour sans lui.

#7

Updated by Lauréline Guérin over 2 years ago

  • Status changed from Solution proposée to Solution validée

ok pour moi; ça simplifie bien le code !

(à pousser après jeudi)

#8

Updated by Valentin Deniaud over 2 years ago

  • Status changed from Solution validée to Résolu (à déployer)
commit 4f81c65622666f2eeced70e3c1f8e3f3f46e7ff3
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Thu Mar 17 16:36:17 2022 +0100

    agendas: always create event recurrences in update method (#62635)

commit b626b248006486a16c51255ba874684d98126838
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Mon Mar 21 10:24:49 2022 +0100

    agendas: remove useless subscription and shared custody code (#62635)

    This includes partial revert of 56300815e7454bc1c364be7168a8de953de5dddd
    and f158dc02ef04f497168ef8ac84d4c505c1274df8.

commit 7769ffabf6759ef6160e25a0c08c4accdc0966c5
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Wed Mar 16 15:16:08 2022 +0100

    agendas: simplify get_open_events method (#62635)

commit d6cf33068bb8dfbf88cb77a2125c0850ed597afd
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Thu Mar 17 12:37:31 2022 +0100

    agendas: remove get_or_create_event_recurrence method (#62635)

commit d707c0569c309e3d5573ce74426a782badb59477
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Thu Mar 17 12:10:09 2022 +0100

    agendas: remove code creating event recurrence on the fly (#62635)

commit 11fa0802ecb10af53e03d2193ea6a50a27ebb877
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Wed Mar 16 15:13:14 2022 +0100

    agendas: stop adding event recurrences on the fly (#62635)

commit ba38629af304dfc145836ab1bae6875b9c3cddff
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Wed Mar 16 15:10:34 2022 +0100

    agendas: always create event recurrences (#62635)
#9

Updated by Transition automatique over 2 years ago

  • Status changed from Résolu (à déployer) to Solution déployée
#10

Updated by Transition automatique over 2 years ago

Automatic expiration

Also available in: Atom PDF