Projet

Général

Profil

Bug #72475

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

Ajouté par Valentin Deniaud il y a plus d'un an. Mis à jour il y a environ un an.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
15 décembre 2022
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

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


Fichiers


Demandes liées

Lié à Chrono - Development #76571: Revoir la logique dans get_effective_timeperiods avec l'introduction de weekday_indexesNouveau13 avril 2023

Actions

Révisions associées

Révision 46b70f6d (diff)
Ajouté par Valentin Deniaud il y a plus d'un an

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

Historique

#2

Mis à jour par Valentin Deniaud il y a plus d'un an

  • Tracker changé de Development à Bug
#3

Mis à jour par Valentin Deniaud il y a plus d'un an

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

Mis à jour par Emmanuel Cazenave il y a plus d'un an

  • Statut changé de Solution proposée à Solution validée
#5

Mis à jour par Valentin Deniaud il y a plus d'un an

  • Statut changé de Solution validée à 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

Mis à jour par Transition automatique il y a plus d'un an

  • Statut changé de Résolu (à déployer) à Solution déployée
#7

Mis à jour par Transition automatique il y a environ un an

Automatic expiration

#8

Mis à jour par Benjamin Dauvergne il y a environ un an

  • Tracker changé de Development à Bug
#9

Mis à jour par Benjamin Dauvergne il y a environ un an

  • Lié à Development #76571: Revoir la logique dans get_effective_timeperiods avec l'introduction de weekday_indexes ajouté

Formats disponibles : Atom PDF