Project

General

Profile

Bug #92240

Fonctionnement du paramètre check-overlaps=true et calcul de chevauchement avec les inscriptions

Added by Benjamin Dauvergne 30 days ago. Updated 29 days ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
24 June 2024
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

chec_overlaps n'est utilisé qu'avec la valeur "true" en recette et et production (via un rapide sudo -u wcs wcs-manage grep --all-tenants check_overlaps).

Par contre dans les tests les seuls vérifications de has_booking_overlaps :

bdauvergne@revestel:~/wd/eo/chrono$ git grep has_booking_overlaps
chrono/api/views.py:                event.has_booking_overlaps = bool(event.day in event.days_with_booking_overlaps)
chrono/api/views.py:                        'has_booking_overlaps': event.has_booking_overlaps if check_overlaps else None,
tests/api/datetimes/test_recurring_events.py:    assert resp.json['data'][0]['has_booking_overlaps'] is False
tests/api/datetimes/test_recurring_events.py:    assert resp.json['data'][1]['has_booking_overlaps'] is False
tests/api/datetimes/test_recurring_events.py:    assert resp.json['data'][2]['has_booking_overlaps'] is False
tests/api/datetimes/test_recurring_events.py:    assert resp.json['data'][0]['has_booking_overlaps'] is True
tests/api/datetimes/test_recurring_events.py:    assert resp.json['data'][1]['has_booking_overlaps'] is False
tests/api/datetimes/test_recurring_events.py:    assert resp.json['data'][2]['has_booking_overlaps'] is False
tests/api/datetimes/test_recurring_events.py:    assert resp.json['data'][0]['has_booking_overlaps'] is True
tests/api/datetimes/test_recurring_events.py:    assert resp.json['data'][1]['has_booking_overlaps'] is False
tests/api/datetimes/test_recurring_events.py:    assert resp.json['data'][2]['has_booking_overlaps'] is True
tests/api/datetimes/test_recurring_events.py:    assert resp.json['data'][0]['has_booking_overlaps'] is True
tests/api/datetimes/test_recurring_events.py:    assert resp.json['data'][1]['has_booking_overlaps'] is False  # event is not marked as overlapping
tests/api/datetimes/test_recurring_events.py:    assert resp.json['data'][2]['has_booking_overlaps'] is True
tests/api/datetimes/test_recurring_events.py:    assert not any(x['has_booking_overlaps'] for x in resp.json['data'])
tests/api/datetimes/test_recurring_events.py:    assert not any(x['has_booking_overlaps'] for x in resp.json['data'])
tests/api/datetimes/test_recurring_events.py:    assert not any(x['has_booking_overlaps'] for x in resp.json['data'])

sont faites avec des slugs d'agenda comme valeurs :
$ git grep check_overlaps tests/api/fillslot/test_recurring_events.py
tests/api/fillslot/test_recurring_events.py:                'check_overlaps': agenda_slugs,
tests/api/fillslot/test_recurring_events.py:                'check_overlaps': agenda_slugs,
tests/api/fillslot/test_recurring_events.py:        'check_overlaps': 'first-agenda,second-agenda',
tests/api/fillslot/test_recurring_events.py:        'check_overlaps': 'first-agenda,second-agenda',
tests/api/fillslot/test_recurring_events.py:        'check_overlaps': 'first-agenda,second-agenda',
tests/api/fillslot/test_recurring_events.py:        'check_overlaps': 'first-agenda,second-agenda',
tests/api/fillslot/test_recurring_events.py:        'check_overlaps': 'first-agenda,second-agenda',
tests/api/fillslot/test_recurring_events.py:        'check_overlaps': 'first-agenda,second-agenda',
tests/api/fillslot/test_recurring_events.py:    params['check_overlaps'] = 'first-agenda'

Avec true ça génère la liste de slug suivante ["true"] qui finit dans :

    @staticmethod
    def annotate_queryset_with_booked_event_overlaps(
        qs, agenda_slugs, user_external_id, start_datetime, end_datetime, exclude_events=None
    ):
        booked_events = Event.objects.filter(
            agenda__slug__in=agenda_slugs,
            start_datetime__gte=start_datetime,
            booking__user_external_id=user_external_id,
            booking__cancellation_datetime__isnull=True,
        )

et je pense que booked_events et donc toujours vide dans ce cas, alors que ce qui souhaité je pense c'est de vérifier vis à vis de tous les évènements visés par l'appel.

On me demande de lister les instances, c'est sur toute je pense, je n'ai pas trouvé d'instance ou check_overlaps soit utilisé avec des slugs d'agenda comme dans les tests.

History

#1

Updated by Valentin Deniaud 29 days ago

Benjamin Dauvergne a écrit :

On me demande de lister les instances, c'est sur toute je pense, je n'ai pas trouvé d'instance ou check_overlaps soit utilisé avec des slugs d'agenda comme dans les tests.

Derrière ma question il y avait savoir si l'usage était bien limité à Publik Famille, c'est le cas : en prod seuls Nimes et famille.publik.love sont concernées (normal, ce paramètre n'est pas documenté).

Ce qu'il se passe c'est que le paramètre est correctement utilisée par les cellules/widgets custom (ne remontent pas dans le grep, donc), puis la vérif au moment du fillslots ne fait rien, c'est assez normal que ça n'ait jamais été détecté car à partir du moment où on passe par le widget la sélection d'évènements incompatibles est interdite.

Pour moi il n'y a rien à gérer dans chrono, c'est un paramétrage obsolète à mettre à jour sur les instances concernées.

#2

Updated by Valentin Deniaud 29 days ago

Benjamin Dauvergne a écrit :

chec_overlaps n'est utilisé qu'avec la valeur "true" en recette et et production (via un rapide sudo -u wcs wcs-manage grep --all-tenants check_overlaps).

Pour que ce soit plus clair notons quand même que check_overlaps doit bien être un booléen pour les API qui ne concernent pas les évènements récurrents.

Sur tout le SaaS de prod on tombe donc à 5 requêtes à corriger, et contrairement à ce que je disais il y a bien des requêtes à l'API qui liste les évènements dans le lot, pas que du fillslots pour réserver : de vrais trous à boucher, donc.

#3

Updated by Benjamin Dauvergne 29 days ago

Valentin Deniaud a écrit :

Sur tout le SaaS de prod on tombe donc à 5 requêtes à corriger, et contrairement à ce que je disais il y a bien des requêtes à l'API qui liste les évènements dans le lot, pas que du fillslots pour réserver : de vrais trous à boucher, donc.

Si tu peux être plus clair ici, que je sache si je déplace le ticket sur Publik famille où s'il y a un vrai sujet chrono.

PS: un vrai sujet sur chrono, et donc j'ouvre un ticket différent sur Publik famille.

PS2: en fait ça m'irait que tu ouvres les tickets parce que j'ai peur de ne pas être clair sur ce qui doit être fait, ou compris des gens qui intègrent. J'ai vu un truc louche mais je ne suis pas sûr de tout comprendre (notamment je ne sais pas pourquoi le cas check-overlaps=slug1,slug2 existe ni à quoi ça sert, tu sauras mieux expliquer.

#4

Updated by Valentin Deniaud 29 days ago

Ici le vrai sujet ce serait qu'il manque de la validation sur ce paramètre, mais c'est tout de même compliqué à rajouter après coup, puisqu'il y a toujours le risque de faire planter des appels en prod qu'on aurait pas vu, ça reste à réfléchir donc.

En tout cas la chose prioritaire à faire c'est bien d'avoir un ticket dans les projets Publik Famille pour corriger les appels, je vais voir pour faire ça.

je ne sais pas pourquoi le cas check-overlaps=slug1,slug2 existe ni à quoi ça sert

Parce que tu veux parfois proposer de réserver la piscine, dans un widget qui montre les créneaux piscine, mais quand même interdire de réserver si le gosse a foot en même temps : donc l'appel datetimes se fait avec ?agendas=piscine&check_overlaps=piscine,foot.

#5

Updated by Benjamin Dauvergne 29 days ago

Valentin Deniaud a écrit :

Ici le vrai sujet ce serait qu'il manque de la validation sur ce paramètre, mais c'est tout de même compliqué à rajouter après coup, puisqu'il y a toujours le risque de faire planter des appels en prod qu'on aurait pas vu, ça reste à réfléchir donc.

J'avais dans l'idée qu'on voudrait permettre la valeur true au contraire, pas l'interdire (mais j'ai encore peut-être pas tout compris).

Parce que tu veux parfois proposer de réserver la piscine, dans un widget qui montre les créneaux piscine, mais quand même interdire de réserver si le gosse a foot en même temps : donc l'appel datetimes se fait avec ?agendas=piscine,check_overlaps=piscine,foot.

J'ai la vague impression que le cas général "toute réservation concomitante pour le même external_user_id est interdite" sera le plus fréquent et le plus facile à utiliser, dans la mesure où on veut interdire quelque chose et que ça devrait se voir dans les tests.

Also available in: Atom PDF