Produits Entr'ouvert » Chrono

• Se limiter à l'API de réservation d'évènements multiples sur plusieurs agendas.
• Garantir l'interdiction de la réservation d'évènements superposés uniquement sur les agendas concernés par l'appel.

L'avantage se serait le code plus simple et moins étendu, et le comportement peut être activé par défaut parce que pas d'existant et assez logique.

• Widget de réservation pour la cantine, deux créneaux pour manger de 12h à 13h ou de 13h à 14h.
• Widget de réservation d'activités, il y a boxe à 13h.
• Le plan ici ne permettra pas d'interdire de manger de 13h à 14h et de réserver la boxe en même temps, parce que widgets séparés. Mais c'est peut être justement ce qu'on veut ?

Le plan "moins global", cad se limiter à l'API de réservations multiples me paraît être le bon.
Pourquoi attaquer l'ensemble de chrono quand (visiblement) seul famille et ces agendas + API de réservations multiples réclament cette feature ?

Le plan ici ne permettra pas d'interdire de manger de 13h à 14h et de réserver la boxe en même temps, parce que widgets séparés. Mais c'est peut être justement ce qu'on veut ?

Oui mais il y aura des cas ou il y aurait superposition et pourtant des temps non-ennemis.
Exemple : une activité est organisée, genre une sortie au ski et la journée est facturée avec ou pas un supplément pour la fourniture du matériel.
Je me voyais bien gérer ce cas avec deux temps (journée et matériel) dans le widget poussé vers les parents.

On peut trouver des manières de gérer ce genre de cas (par exemple en mettant des horaires fictifs au temps matériel), bref en paramétrant de manière "astucieuse".
Mais il y aura des cas (tu exposes celui d'activités organisées pendant un autre temps d'accueil, cas typique, les TAP-NAP qui existent encore dans certaines collectivités) ou ce contournement sera compliqué (surtout quand il faut comptabiliser du temps).

Si cela ne met pas une complexité folle dans le code, il faudrait pouvoir inclure ou exclure de cette règle de temps ennemis des agendas, des événements (y compris dans le même agenda).
A discuter, car partir du principe que nous pourrions ignorer ce cas en version 1 de Publik Famille pour le mettre en place quand le cas se présentera, est très entendable.

• Support dans l'API /agendas/datetimes/
  • On récupère une nouvelle clé overlaps pour chaque évènement, c'est une liste contenant les slugs des évènements qui le chevauche, c'est à destination du widget.
• Support dans les API /agenda/xxx/events/fillslots/ et /agendas/events/fillslots/
  • Refus de la réservation si deux évènements se chevauchent, c'est le comportement par défaut et dans l'attente d'un cas d'usage contraire ce n'est pas désactivable.

À noter aussi qu'un évènement qui n'a pas de durée n'est pas concerné par ces règles (ça aide peut-être pour le cas « matériel de ski » décrit par Stéphane).

Lauréline Guerin a écrit :

Il faudrait aussi gérer la réservation récurrente non ?

Fait dans 0002. Sacrément galère, je n'ai pas réussi à avoir ce que je voulais en une requête comme dans 0001, du coup je repasse en python derrière et c'est plutôt moche. (pour les archives j'ai même sollicité Pierre D ici https://pad.libre-entreprise.org/p/eo-sql-valentin mais je crois que la solution full SQL n'est pas représentable avec l'ORM)

Lauréline Guerin a écrit :

Pas de paramètre optionnel passé aux endpoints pour activer ou non cette limitation ?

Nope, vu le nombre de paramètres déjà présents je préfère attendre une demande explicite avant d'en introduire un nouveau.

dans 0001, test_datetimes_multiple_agendas_overlapping_events,
('foo-bar@event', ['foo-bar@event-containing-all-events', 'foo-bar-2@event']),

foo-bar@event commence à midi et termine à 14H, foo-bar-2@event commence à 14H; il ne devrait pas y avoir d'overlaps, si ?

foo-bar-2@event commence à 13h, tu confonds avec foo-bar-2@event-1 ! (ça appelait bien sûr renommage et j'ai donc renommé pour que les tests soient plus évidents)

0002, dans test_recurring_events_api_list_overlapping_events, possible de rajouter des events qui partagent juste une borne ? (comme dans 0001, un event qui finit à 14H, un autre qui commence à la même heure)

Ouep, j'ai fait ça partout.

Nope, vu le nombre de paramètres déjà présents je préfère attendre une demande explicite avant d'en introduire un nouveau.

Niveau perfs, ça va pas être trop impactant ?

foo-bar-2@event commence à 13h, tu confonds avec foo-bar-2@event-1 ! (ça appelait bien sûr renommage et j'ai donc renommé pour que les tests soient plus évidents)

Merci, c'est plus facile à lire avec ces nouveaux labels :)

Lauréline Guerin a écrit :

On affiche à la semaine, mais tout est loadé; on navigue entre les semaines grâce à du JS

OK je savais pas, revoici une version avec des paramètres.

Lauréline Guerin a écrit :

(et du coup je me dis qu'on pourrait - si c'est pas déjà fait - faire l'économie du calcul sur les événements hors délais (passés, hors délais de prévenance), mais quand même remontés par datetimes, en disabled)

C'est un peu de boulot pour arriver à ça, ces vérifs sont faites à posteriori en python et ça demanderait de les jouer d'abord en SQL, je pense qu'on pourra ouvrir un autre ticket.

Lauréline Guerin a écrit :

L'annotation ne dépend pas de check_overlaps ?

C'était juste une astuce pour éviter un niveau d'indentation en plus en exploitant la paresse du and, mais puisque ça n'apporte rien, revoici en plus clair.

commit e629fccaec0ee9776a0e0aec3f2cec944ad160fd
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Mon May 2 11:29:39 2022 +0200

    api: forbid overlapping recurring events booking (#64383)

commit b359c3f1fff4f91aee9dbc08f0ff1f2c0d56b68a
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Thu Apr 21 11:48:57 2022 +0200

    api: forbid overlapping events booking (#64383)