Projet

Général

Profil

Development #62635

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

Ajouté par Valentin Deniaud il y a environ 2 ans. Mis à jour il y a environ 2 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
10 mars 2022
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

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 ?


Fichiers

Révisions associées

Révision ba38629a (diff)
Ajouté par Valentin Deniaud il y a environ 2 ans

agendas: always create event recurrences (#62635)

Révision 11fa0802 (diff)
Ajouté par Valentin Deniaud il y a environ 2 ans

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

Révision d707c056 (diff)
Ajouté par Valentin Deniaud il y a environ 2 ans

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

Révision d6cf3306 (diff)
Ajouté par Valentin Deniaud il y a environ 2 ans

agendas: remove get_or_create_event_recurrence method (#62635)

Révision 7769ffab (diff)
Ajouté par Valentin Deniaud il y a environ 2 ans

agendas: simplify get_open_events method (#62635)

Révision b626b248 (diff)
Ajouté par Valentin Deniaud il y a environ 2 ans

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

This includes partial revert of 56300815e7454bc1c364be7168a8de953de5dddd
and f158dc02ef04f497168ef8ac84d4c505c1274df8.

Révision 4f81c656 (diff)
Ajouté par Valentin Deniaud il y a environ 2 ans

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

Historique

#1

Mis à jour par Lauréline Guérin il y a environ 2 ans

  • Description mis à jour (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

Mis à jour par Emmanuel Cazenave il y a environ 2 ans

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

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

  • Description mis à jour (diff)
#4

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

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

Mis à jour par Lauréline Guérin il y a environ 2 ans

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

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

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

Mis à jour par Lauréline Guérin il y a environ 2 ans

  • Statut changé de Solution proposée à Solution validée

ok pour moi; ça simplifie bien le code !

(à pousser après jeudi)

#8

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

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

Mis à jour par Transition automatique il y a environ 2 ans

  • Statut changé de Résolu (à déployer) à Solution déployée
#10

Mis à jour par Transition automatique il y a presque 2 ans

Automatic expiration

Formats disponibles : Atom PDF