Project

General

Profile

Development #51360

Evénements récurrents - délais de réservation

Added by Lauréline Guerin 2 days ago. Updated 1 day ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
23 Feb 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

Observations en local:
Créer un agenda de type événement, avec en délai de réservation min et max 0.
Créer un event récurrent (par exemple tous les lundi à midi).
Dans la vue mensuelle, on voit bien apparaître un event tous les lundi à midi, non marqués comme hors délai.
Dans l'api datetimes, aucun event ne sort.

Je ne sais pas si c'est un soucis d'affichage sur la vue mensuelle à cause des délais à 0, ou si c'est un soucis avec la récurrence.

History

#1

Updated by Valentin Deniaud 2 days ago

Pour le moment c'est normal, quand on a pas de borne temporelle max on ne montre pas les évènements récurrents.

Si il y a une date de réservation max, pas de problèmes on l'utilise automatiquement. Mais en son absence il faut spécifier date_end à l'API /datetimes/ (ça devra être précisé le jour où il y aura de la doc).

Tu aurais attendu quel comportement ?

(par contre actuellement le comportement est incohérent si on est dans la situation où certaines récurrences sont en base et pas d'autres, /datetimes/ va montrer une vue partielle bizarre, je peux patcher ça ici)

#2

Updated by Lauréline Guerin 2 days ago

ce que j'observe:
dans un agenda avec un Délai de réservation maximal > 0,
- un event récurrent sans date de fin affiche dans la vue mensuelle des events réservables et des events en dehors de la période d'inscription
- les récurrences dans la période de réservation de cet event remontent dans l'API datetimes

dans un agenda avec un Délai de réservation maximal == 0,
- un event récurrent sans date de fin n'affiche dans la vue mensuelle que des events réservables
- aucune récurrence ne remonte dans l'API datetimes

Il y a une incohérence entre l'UI et l'API, mais si je comprends bien c'est le comportement souhaité ?

#3

Updated by Valentin Deniaud 2 days ago

Lauréline Guerin a écrit :

c'est le comportement souhaité ?

Ça m'a paru le seul comportement possible, puisqu'on ne peut pas retourner un nombre infini d'évènements dans du JSON, et mettre une coupure arbitraire genre 1 an ne m'a pas paru censé.

#4

Updated by Lauréline Guerin 2 days ago

Du coup on en revient presque à l'idée d'imposer une date de fin de récurrence :)
Sachant que les activités récurrentes sont généralement mises en place sur une année scolaire

#5

Updated by Valentin Deniaud 2 days ago

Je ne vois pas quel est le problème derrière ce ticket, il y a quel cas d'usage ?

#6

Updated by Lauréline Guerin 1 day ago

Le problème:

On a un événement récurrent. En fonction de plusieurs paramètres (présence ou non d'un délai max de réservation, d'une date de réservation, ou d'un filtre date_end), l'API datetimes peut ne pas renvoyer de slots.

Ca me paraît bancal.

Dans un ticket d'optimisation de l'API datetimes Benjamin proposait de limiter la période couverte (et faire évoluer w.c.s. pour qu'il ne récupère que les slots d'une période donnée), parce que renvoyer la terre entière ce n'est pas forcément pertinent - je ne sais plus si c'était dans un commentaire, par email ou sur jabber; peut-être qu'il faudrait regarder de ce côté-là pour avoir un comportement stable ?

#7

Updated by Valentin Deniaud 1 day ago

Dac mais comme le cas où on ne renvoie rien est bien précis, agenda sans délai max de réservation + évènement récurrent sans date de fin de récurrence, j'imaginais possible de le documenter : « dans ce cas, précisez un paramètre date_end sinon l'API ne sait pas quoi renvoyer » (on pourrait ajouter « et vous non plus », d'où ma question sur les cas d'usages, je n'en vois pas).

Mais oui je comprends maintenant que ce comportement c'est un peu ignorer silencieusement une erreur au lieu de la signaler : pour faire simple avant d'en venir à l'idée de Benj, on pourrait lever une APIError si on détecte qu'on est dans ce cas, en demandant explicitement un date_end dans le message d'erreur ?

#8

Updated by Lauréline Guerin 1 day ago

Comment tu gèrerais le cas où dans un même agenda tu as des récurrents avec date de fin, des events non récurrents, et des récurrences sans limite, et pas de end_date passé en filtre ?

#9

Updated by Valentin Deniaud 1 day ago

Oui on voit venir le cas où on a un agenda en prod, pas de délai de réservation max et des évènements avec fin de récurrence, et où on a pas envie qu'ajouter un évènement sans fin de récurrence fasse d'un coup planter tous les appels à /datetimes/. Donc mauvaise idée l'APIError.

Also available in: Atom PDF