Produits Entr'ouvert » Chrono

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)

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é ?

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é.

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

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

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 ?

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 ?

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 ?

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.

yes tu peux fermer