Produits Entr'ouvert » Chrono

Comme c'est le cas pour les exceptions importées depuis un ics distant, l'ajout/mise à jour des exceptions depuis un fichier devrait également se faire en se basant sur l'uid.

Le premier ICS que tu modifies dans le test montre qu'il reste un autre cas problématique, à savoir des événements sans UID et qui ont le même nom. Ton patch ici ne concerne que le second cas (même nom mais heureusement, uid différentes).

Il faut donc régler le premier cas, et je pense que la seule solution est de dire que l'import a raté, ics mal formatté, il manque des uid.

À rererelire ensemble, non, c'est pas comme ça qu'il faut faire, en fait le bug est plus profond, on fait du "update_or_create" sur l'import d'un ICS à la main, alors que non, faut pas faire d'update, ça n'a pas de sens, faut juste ajouter tout ce que l'ics comporte.

Et ne surtout par utiliser external_id qui est une indication qui veut dire "ça vient d'un ICS distant"

Serghei Mihai a écrit :

Yep.
Sans toucher aux evenements réccurents qui se mettent à jour en fonction du titre et numéro de séquence.

• Je crois que la ligne 534 soit redondante avec 527 dans chrono/agendas/models.py

• Si je comprends bien, et comme je ne connais pas bien chrono je dis ce que j'ai compris, mais c'est peut-être/sûrement pas ce que tu as cherché à faire : ligne 538, label='' permet de filtrer sur les objets à label == '' et **kwargs, mais mettre à jour avec le dict event comme paramètre pour default. C'est donc pour ça que tu as bien forcé la ligne 534 pour être sûr de ne pas avoir kwargs['label'] dans le filtre. Or là j'ai l'impression que tu te sers de filtrer sur label='' pour être sûr de ne rien trouver d'existant dans la base ?

• tox=OK.

Elias Showk a écrit :

Or là j'ai l'impression que tu te sers de filtrer sur label='' pour être sûr de ne rien trouver d'existant dans la base ?

Même avis, et pour moi c'est juste une bidouille... pas bien :)

Pour mieux s'entendre, faut (d'abord) revoir les tests :

• import d'un ics avec un "event 1" : un seul élément doit être créé (event 1)
• ajouter un event2 dans cet ics, l'importer : un seul élément doit être créé (event 2), l'autre pas touché
• modifier le titre de l'event 1, importer l'ics : un seul élément doit être mis à jour (event 1, nouveau titre)
• modifier la date de l'event 1, importer l'ics : un seul élément doit être créé (event 1 qui en fait n'a rien à voir avec l'ancien, qui reste là, tranquille)
• à la fin, vérifier qu'il y a 3 events : event 1, event 2, event 1

• pareil
• (et je suis pas du tout convaincu par l'usager des UID, au contraire, mais c'est un autre sujet ; pour le même algo basé sur dtstart/dtend/label devrait s'appliquer et voilà)

Sur les récurrents, mon avis c'est que l'algo devrait les traiter comme des event classiques, ie avoir une méthode "add_exception(event)" générique, qui gère les events ou leur récurrence, tout pareil. En fait, allez, de mon point de vue, l'algo m'est pas assez élégant actuellement pour permettre de faire un patch clair.

Je propose ici de reprendre le fonctionnement pour l'ics local et traiter le cas de l'ics distant à part.

Pour moi la modification du kwargs dans la boucle des évènements récurrents va créer des doublons, la clé pour un évènement récurrent d'une source distante c'est (external_id, recurrence_id), ça ne doit pas changer, il faudrait au minimum protéger ces deux ligne par un if keep_synced_by_uid: juste avant.

• pour un .ics distant, les exceptions avec external_id sont entièrement esclaves de celui-ci on supprime, on met à jour, on crée.
• pour un .ics uploadé on fonctionne uniquement en ajout, mais donc jusqu'à présent via le label on pouvait éviter les doublons, là on veut remplacer ça par une recherche via start/end, soit.

Je me dis qu'en fait on devrait prendre chaque vevent et voir ce dont on dispose, si on a un uid même pour un .ics uploadé on s'en sert et on gère ça comme pour un .ics distant, si pas d'uid on fonctionne en simple ajout en vérifiant auparavant qu'on a pas une exception à la même date pour éviter les doublons évidents.

Benjamin Dauvergne a écrit :

Je me dis qu'en fait on devrait prendre chaque vevent et voir ce dont on dispose, si on a un uid même pour un .ics uploadé on s'en sert et on gère ça comme pour un .ics distant, si pas d'uid on fonctionne en simple ajout en vérifiant auparavant qu'on a pas une exception à la même date pour éviter les doublons évidents.

À noter qu'il est impossible d'avoir un .ics uploadé avec UID mélangé avec un .ics distant pour un même guichet, les évènements uploadés seront nettoyés à chaque synchro de l'.ics distant car leur UID n'est pas présent (tout ce que ça indique c'est qu'une source unique serait vraiment mieux dans tous les cas).