Produits Entr'ouvert » Chrono

Je regarde le getrruleset sur ma copie de vobject et elle me semble pouvoir retourner None, ce qui échouerait ici.

Ajouter dans test_timeperiodexception_creation_from_ics_with_recurrences un passage sur un ics qui faisait planter ?

(aussi, je préfère éviter les (fixes: #...) dans les messages de commit (qui font faire des trucs automatiquement pas toujours raisonnables))

Frédéric Péters a écrit :

Je regarde le getrruleset sur ma copie de vobject et elle me semble pouvoir retourner None, ce qui échouerait ici.

Oui tout à fait, en plus il n'y a pas de len() non plus apparemment, il faut faire .count() j'ai fait nawak je reprends.

Ajouter dans test_timeperiodexception_creation_from_ics_with_recurrences un passage sur un ics qui faisait planter ?

Yep.

(aussi, je préfère éviter les (fixes: #...) dans les messages de commit (qui font faire des trucs automatiquement pas toujours raisonnables))

Bon à la correction je me rends compte qu'il y a un problème sous-jacent plus embêtant, là pour l'instant mon fix qui tourne avec le fichier transmis par atreal:

diff --git a/chrono/agendas/models.py b/chrono/agendas/models.py
index fc09bb2..f414c26 100644
--- a/chrono/agendas/models.py
+++ b/chrono/agendas/models.py
@@ -529,6 +529,7 @@ class Desk(models.Model):

                 kwargs = {}
                 kwargs['desk'] = self
+                kwargs['recurrence_id'] = 0
                 if keep_synced_by_uid:
                     kwargs['external_id'] = vevent.contents['uid'][0].value
                 else:
@@ -539,7 +540,7 @@ class Desk(models.Model):
                     obj, created = TimePeriodException.objects.update_or_create(defaults=event, **kwargs)
                     if created:
                         total_created += 1
-                else:
+                elif vevent.rruleset.count():
                     # recurring event until recurring_days in the future
                     from_dt = start_dt
                     until_dt = update_datetime + datetime.timedelta(days=recurring_days)

Le premier changement c'est parce que beaucoup de leur évènements dans leur fichier .ics ont le même summary (SUMMARY:X3M) et dans le cas de l'import d'un fichier .ics on utilise le summary comme label et le label comme clé, dans le cas d'un import distant on utilise le UID comme external_id et external_id comme clé; de plus on nettoie en sortie les UID devenus inconnus (et les recurrence_id supérieurs au dernier créé pour chaque external_id, enfin chaque VEVENT), donc là l'idée pour une récurrence qui génère le même start/end qu'un autre évènement et avec le même label c'est de spécifier recurrence_id à 0 comme clé par défaut (recurrence_id a pour valeur par défaut 0 donc ça roule).

Le deuxième c'est pour le problème soulevé par la trace, un VEVENT avec une RRULE dont le UNTIL est avant DTSTART (donc récurrence vide).

Leur fichier est long dans mon test je ne valide rien de ce qui est chargé (ça crée 87 exceptions), est-ce que je réduis le fichier au VEVENT qui pose problème ? Ça ne couvrira plus le problème corrigé par mon premier "hunk".

Le premier changement c'est parce que beaucoup de leur évènements dans leur fichier .ics ont le même summary (SUMMARY:X3M) et dans le cas de l'import d'un fichier .ics on utilise le summary comme label et le label comme clé

Il y a #25962 sur le sujet.

Frédéric Péters a écrit :

Le premier changement c'est parce que beaucoup de leur évènements dans leur fichier .ics ont le même summary (SUMMARY:X3M) et dans le cas de l'import d'un fichier .ics on utilise le summary comme label et le label comme clé

Il y a #25962 sur le sujet.

Sans cette modif le fichier en question va continuer à cracher au chargement, l'autre ticket c'est un changement de comportement, ici on conserve le comportement actuel mais au moins on ne crashe pas.