Project

General

Profile

Bug #72475

Les périodes horaires uniques se masquent les unes les autres

Added by Valentin Deniaud almost 2 years ago. Updated over 1 year ago.

Status:
Fermé
Priority:
Normal
Category:
-
Target version:
-
Start date:
15 December 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Si elles sont même jour de la semaine + même heure...


Files


Related issues

Related to Chrono - Développement #76571: Revoir la logique dans get_effective_timeperiods avec l'introduction de weekday_indexesNouveau13 April 2023

Actions

Associated revisions

Revision 46b70f6d (diff)
Added by Valentin Deniaud almost 2 years ago

agendas: compare all WeekTime attributes by default (#72475)

History

#2

Updated by Valentin Deniaud almost 2 years ago

  • Tracker changed from Développement to Bug
#3

Updated by Valentin Deniaud almost 2 years ago

Joli bug.

Ça se joue dans Agenda.get_effective_time_periods_meetings et l'utilisation de itertools.groupby :

for weektime_interval, time_periods in itertools.groupby(
    time_periods.prefetch_related('desk').order_by('weekday', 'start_time', 'end_time'),
    key=TimePeriod.as_weektime_interval,
)

Ici on ordonne le queryset « time_periods » en SQL.
Or dans la doc de Python, https://docs.python.org/3/library/itertools.html#itertools.groupby

Generally, the iterable needs to already be sorted on the same key function.

Donc on voit ici qu'on est à moitié dans les clous, on n'a pas ordonné avec la même fonction mais avec du SQL qu'on espère équivalent.

Sauf que depuis que time_periods a gagné un champ weekday_indexes (puis date), ce n'est plus équivalent.

Le péché originel qui fait que ce n'est plus équivalent c'est #65849.

Ce patch c'est moi qui me suit aperçu que la comparaison entre période d'exclusion et période horaire avec numéro de semaine se passait mal, et qui me suit dit « ok on va pas comparer ».

Mais si on ne compare plus on tombe sur le bug présent, on regroupe des périodes qui en fait ne sont pas les même (pas le même weekday_indexes, puis pas la même date). Mais ce regroupement fautif est rare, masqué par l'utilisation borderline de itertools.groupby.

(en vrai j'ai peur de toucher à cette ligne avec itertools donc je la laisse tranquille, elle n'est pas en soit fautive elle rend juste l'analyse plus compliquée)

Tout ça pour dire, le fix c'est de revenir sur #65849 et d'inverser la logique : plutôt que de ne jamais comparer, toujours tout comparer et court-circuiter la comparaison au seul endroit où ça foire.

(et là dessus on est pas aidés par la généricité du code dans interval.py, le code pourrait être nettement moins générique et beaucoup plus simple à suivre/faire évoluer)

#4

Updated by Emmanuel Cazenave almost 2 years ago

  • Status changed from Solution proposée to Solution validée
#5

Updated by Valentin Deniaud almost 2 years ago

  • Status changed from Solution validée to Résolu (à déployer)
commit 46b70f6d0533044bd03919927c39abe1a0bbe10c
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Thu Dec 15 15:00:25 2022 +0100

    agendas: compare all WeekTime attributes by default (#72475)
#6

Updated by Transition automatique almost 2 years ago

  • Status changed from Résolu (à déployer) to Solution déployée
#7

Updated by Transition automatique almost 2 years ago

Automatic expiration

#8

Updated by Benjamin Dauvergne over 1 year ago

  • Tracker changed from Développement to Bug
#9

Updated by Benjamin Dauvergne over 1 year ago

  • Related to Développement #76571: Revoir la logique dans get_effective_timeperiods avec l'introduction de weekday_indexes added

Also available in: Atom PDF