Projet

Général

Profil

Development #19070

prise en compte d'un ics distant pour les exceptions

Ajouté par Serghei Mihai il y a plus de 6 ans. Mis à jour il y a plus de 6 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
28 septembre 2017
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

A travers http/webcal avec une fréquence de mise à jour à définir.


Fichiers

0001-manager-add-support-for-remote-ICS-file-with-excepti.patch (10,8 ko) 0001-manager-add-support-for-remote-ICS-file-with-excepti.patch Serghei Mihai, 04 octobre 2017 12:33
0001-manager-add-support-for-remote-ICS-file-with-excepti.patch (10,9 ko) 0001-manager-add-support-for-remote-ICS-file-with-excepti.patch Serghei Mihai, 09 octobre 2017 08:27
0001-agenda-add-remote-timeperiods-url-for-desks-19070.patch (9,61 ko) 0001-agenda-add-remote-timeperiods-url-for-desks-19070.patch Serghei Mihai, 09 octobre 2017 11:04
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (23,8 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 09 octobre 2017 16:34
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (24,2 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 09 octobre 2017 16:40
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (25,1 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 11 octobre 2017 12:47
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (25,1 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 11 octobre 2017 14:08
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (30,8 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 17 octobre 2017 00:04
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (30,8 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 17 octobre 2017 09:35
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (29,6 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 19 octobre 2017 00:14
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (29,5 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 19 octobre 2017 19:30
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (30 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 20 octobre 2017 09:48
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (31,3 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 20 octobre 2017 12:11
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (33,3 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 27 octobre 2017 13:49
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (33,2 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 27 octobre 2017 14:44
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (32,5 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 31 octobre 2017 10:41
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (32,5 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 31 octobre 2017 16:29
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (32,3 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 02 novembre 2017 11:03
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (32,6 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 02 novembre 2017 12:13
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (32,3 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 02 novembre 2017 13:04
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (32,3 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 02 novembre 2017 14:55
0001-agenda-add-support-for-remote-calendar-file-with-exc.patch (32,3 ko) 0001-agenda-add-support-for-remote-calendar-file-with-exc.patch Serghei Mihai, 02 novembre 2017 15:56

Révisions associées

Révision 71f5b91c (diff)
Ajouté par Serghei Mihai il y a plus de 6 ans

agenda: add support for remote calendar file with exceptions (#19070)

Remote calendars can be specified by desk and updated hourly, or used once.

Historique

#1

Mis à jour par Serghei Mihai il y a plus de 6 ans

  • Sujet changé de prendre en compte un ics disant pour les exceptions à prendre en compte un ics distant pour les exceptions
#2

Mis à jour par Serghei Mihai il y a plus de 6 ans

  • Sujet changé de prendre en compte un ics distant pour les exceptions à prendre en compte d'un ics distant pour les exceptions
#3

Mis à jour par Serghei Mihai il y a plus de 6 ans

Première version avec le champ "url" dans le formulaire.
Je suis un train de faire un autre patch avec une commande Django pour mettre à les infos à partir du fichier distant, à mettre dans un cron.

#4

Mis à jour par Josué Kouka il y a plus de 6 ans

Faudrait aussi tester le cas ou ni un fichier et une url sont fournis (couverture manager/forms.py:180)

#6

Mis à jour par Serghei Mihai il y a plus de 6 ans

Pour pouvoir mettre à jour regulièrement des exceptions j'ai rajouté un champ au modèle Desk qui sera utilisé par une commande qui fera la synchro.
Il manque le cron pour lancer la commande toutes les heures, mais je colle déjà ça pour validation.

#7

Mis à jour par Frédéric Péters il y a plus de 6 ans

Error %s is returned while trying to get file.

→ Failed to retrieve remote calendar (HTTP error %s).

URL is unreachable.

→ Failed to retrieve remote calendar (connection error).

Mais pourquoi ces deux-là et pas les autres ? Timeout ou erreur de certificat pourraient clairement arriver.

#8

Mis à jour par Frédéric Péters il y a plus de 6 ans

Mais pourquoi ces deux-là et pas les autres ? Timeout ou erreur de certificat pourraient clairement arriver.

Mais aussi, pourquoi répéter ça ici alors que create_timeperiod_exceptions_from_remote_ics() le fait déjà ?

#9

Mis à jour par Frédéric Péters il y a plus de 6 ans

Je ne capte pas la séparation entre les deux patchs; pour moi tout pourrait être dans un seul.

#10

Mis à jour par Frédéric Péters il y a plus de 6 ans

<p>{% trans "You could upload a local file or specify an address to remote file." %}</p>

s/could/can/; s/local// ; s/remote file/remote calendar/.

#11

Mis à jour par Serghei Mihai il y a plus de 6 ans

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

Mais pourquoi ces deux-là et pas les autres ? Timeout ou erreur de certificat pourraient clairement arriver.

L'erreur de certificat sera interceptée par l'exception ConnectionError.
J'ai rajouté la prise en compte du Timeout.

Le check de l'url deporté dans une fonction séparée pour être utilisée dans le formulaire de création/modification d'un guichet.
Textes mis à jour aussi.

Le cron hourly ajouté.

#13

Mis à jour par Josué Kouka il y a plus de 6 ans

Il manque le test (passant) ou l'on crée un guichet avec une url distante.
Sinon, ok pour moi.

#14

Mis à jour par Serghei Mihai il y a plus de 6 ans

Et voici le test manquant pour le bon ajout d'un guichet avec un calendrier distant.

#15

Mis à jour par Josué Kouka il y a plus de 6 ans

+++ b/debian/chrono.cron.hourly
@@ -0,0 +1,4 @@
+#!/bin/sh
+
+/sbin/runuser -u chrono /usr/bin/chrono-manage -- tenant_command sync_desks_timeperiod_exceptions --all-tenants
+

ligne en trop.

#17

Mis à jour par Frédéric Péters il y a plus de 6 ans

Trier les imports dans chrono/agendas/models.py et .../sync_desks_timeperiod_exceptions.py

L'erreur de certificat sera interceptée par l'exception ConnectionError.

Mais c'est dommage de cacher ça, avoir "connection error" ne va pas aider le debug. En fait ce que j'imaginais c'est que la multitude d'exceptions étant là, on se trouve juste avec "Failed to retrieve remote calendar (%s)" % exception.

Le check de l'url deporté dans une fonction séparée pour être utilisée dans le formulaire de création/modification d'un guichet.

Et ici ce que j'imaginais c'était que la création ait lieu dès ce moment plutôt que ne rien dire et espérer que l'agent se dise que ça ira mieux une heure plus tard.

s/New eve/New Year's Eve/

~~

Aussi, c'est trop tard pour cette mise à jour, même s'il y a ack, il ne faut pas pousser avant vendredi.

#18

Mis à jour par Paul Marillonnet il y a plus de 6 ans

  • Pas grave que l'URL utilisée dans get_remote_calendar n'est loggée nulle part, dans aucun des trois cas d'exception ?
  • self.data['...'] au lieu de self.data.get('...'), c'est pas grave ?
  • Pas moyen de compacter un peu is_valid() pour un peu plus de lisibilité (deux return au lieu de trois actuellement) ?
    Genre en
        def is_valid(self):
            if self.data['timeperiod_exceptions_remote_url']:
                try:
    [...]
            return super(DeskForm, self).is_valid()
    
#19

Mis à jour par Serghei Mihai il y a plus de 6 ans

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

Trier les imports dans chrono/agendas/models.py et .../sync_desks_timeperiod_exceptions.py

Ok.

Mais c'est dommage de cacher ça, avoir "connection error" ne va pas aider le debug. En fait ce que j'imaginais c'est que la multitude d'exceptions étant là, on se trouve juste avec "Failed to retrieve remote calendar (%s)" % exception.

Ok. Message explicite sur l'erreur SSL.

Et ici ce que j'imaginais c'était que la création ait lieu dès ce moment plutôt que ne rien dire et espérer que l'agent se dise que ça ira mieux une heure plus tard.

Je ne suis pas sûr de comprendre, la création/modification du guichet doit avoir lieu même si l'URL du calendar n'est pas bonne?

s/New eve/New Year's Eve/

Ok.

Aussi, c'est trop tard pour cette mise à jour, même s'il y a ack, il ne faut pas pousser avant vendredi.

Je visais qu'au moins ce ticket passe en prod pour Villejuif sur les deux qu'ils attendent, mais bon, raté.

#20

Mis à jour par Frédéric Péters il y a plus de 6 ans

Ok. Message explicite sur l'erreur SSL.

Manque le patch mais non, ce n'est pas mon souhait. Mon souhait c'est de laisser à requests le soin de fournir un détail technique, que le message "humain", il soit unique.

Et ici ce que j'imaginais c'était que la création ait lieu dès ce moment plutôt que ne rien dire et espérer que l'agent se dise que ça ira mieux une heure plus tard.

Je ne suis pas sûr de comprendre, la création/modification du guichet doit avoir lieu même si l'URL du calendar n'est pas bonne?

Bon en fait c'est parce qu'il y a totale confusion sur le fond et qu'il y a deux endroits alors que j'en imaginais un seul : j'étais sur l'idée que la fenêtre d'ajout d'un fichier d'exception accepte une URL en plus d'un fichier.

Mais ce qu'il y a aussi eu, c'est la possibilité d'une URL dans la fenêtre de création/édition de guichetet je ne m'attendais pas à cette partie, je ne pense pas que ça soit une bonne idée. (on veut créer un guichet on espère juste taper un nom mais non ça commence à parler d'url d'ics).

Pour moi, l'association d'un guichet à une URL ics, ça doit être la fenêtre "importer des exceptions" existante, et uniquement ça.

~~

Je visais qu'au moins ce ticket passe en prod pour Villejuif sur les deux qu'ils attendent, mais bon, raté.

"Bon raté" ça se sait dès le lundi soir. Et idéalement même dès le vendredi, vu qu'il n'y a rien d'annoncé à propos de ce ticket dans les notes de mise à jour.

#21

Mis à jour par Frédéric Péters il y a plus de 6 ans

  • Sujet changé de prendre en compte d'un ics distant pour les exceptions à prise en compte d'un ics distant pour les exceptions
#22

Mis à jour par Frédéric Péters il y a plus de 6 ans

Pour reprendre le tout, pour moi, ce que ce ticket devrait amener :

  • modification à la boite d'importation d'un ics pour permettre une URL
    • cette URL est alors attachée au guichet
  • le guichet contient comme exceptions les événements présents à l'URL
    • ça veut dire mise à jour régulière, et que cette mise à jour ajoute mais également supprime des exceptions
    • ça veut dire qu'il faut marquer d'un identifiant externe les exceptions tirées d'un ics (UID est obligatoire, ça tombe bien, il serait à préfixer, genre "desk%d:", ce qui permettra plus d'avoir une gestion d'exceptions globales, qui utiliseront "global:" comme préfixe)
  • si la boite d'importation d'un ics est ouverte par la suite, le champ URL est déjà rempli, et il est possible de le vider
    • on ne compte pas gérer plusieurs URL pour un guichet
#23

Mis à jour par Serghei Mihai il y a plus de 6 ans

Ok.

J'utilise le timestamp de creation/mise à jour d'une exception pour leur suppression lors de la synchro.
j'informe dans le help_text du calendrier distant qu'il sera mis à jour toutes les heures.

#24

Mis à jour par Thomas Noël il y a plus de 6 ans

Détail, mais je ne suis pas bien fan de passer par cron.hourly parce qu'on ne sait pas à quel moment ça se passe ("ça dépend"). S'agissant d'un truc de calendrier je trouve qu'il serait plus compréhensible (du moins plus facile à expliquer) de faire ça à « 0 * * * * »

#26

Mis à jour par Frédéric Péters il y a plus de 6 ans

+        except (requests.exceptions.SSLError, requests.exceptions.ConnectionError, requests.exceptions.Timeout) as e:

Toujours pas (si jamais requests ajoute une autre exception ?). Il faut attraper la classe de base, RequestsException. Aussi, il faut faire référence à requests.RequestException et requests.HTTPError, pas à requests.exceptions.whatever (ils sont importés à la "racine" du module pour permettre à requests d'évoluer dans sa structuration interne sans casser les appelants).

 <form method="post" enctype="multipart/form-data">
+  <p>{% trans "You can upload a file or specify an address to remote calendar." %}</p>

Y taper une classe, qu'un style différent des <p> des champs puisse lui être appliqué. A minima aussi, concernant le message, "to a remote calendar".

Retirer une URL distante devrait retirer les exceptions liées.

J'ai lancé la commande sync_desks_timeperiod_exceptions et j'ai eu quantité de messages "DateTimeField TimePeriodException.end_datetime received a naive datetime", il doit y avoir un truc pas correct quelque part.

À défaut de pouvoir retirer les exceptions j'ai vidé le fichier, mais alors la commande échoue avec "chrono.agendas.models.ICSError: Le fichier ne contient aucun événement.".

Je ne suis vraiment pas fan d'utiliser logger dans les commandes de gestion, dans une configuration de base Django le résultat va être :

No handlers could be found for logger "chrono.manager.management.commands.sync_desks_timeperiod_exceptions"

plutôt qu'une information utile. (ça veut peut-être dire à un moment à nouveau remettre le sujet du logging sur la table)

Plutôt poser la commande dans chrono/agendas/management/. (import/export sont des commandes génériques qui pourraient ne pas être limitées à du contenu de chrono/agendas/, la commande de synchro est vraiment attachée uniquement aux modèles de chrono/agendas/).

#27

Mis à jour par Serghei Mihai il y a plus de 6 ans

Remarques prises en compte.

Ok pour ne pas utiliser le logger, mais dans ce cas lever une CommandError, quite à recevoir des mails.
Commande deplacée dans le module agendas.

#28

Mis à jour par Frédéric Péters il y a plus de 6 ans

E       ImportError: No module named management.commands.sync_desks_timeperiod_exceptions
#29

Mis à jour par Frédéric Péters il y a plus de 6 ans

        for desk in Desk.objects.exclude(timeperiod_exceptions_remote_url__isnull=True).exclude(timeperiod_exceptions_remote_url=''): 

Il n'y a pas une bonne pratique de pas cumuler null=True et blank=True, pour justement éviter ça ?

#30

Mis à jour par Serghei Mihai il y a plus de 6 ans

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

ImportError: No module named management.commands.sync_desks_timeperiod_exceptions

Tu as eu ça à quel moment?

J'ai retiré le null=True

#31

Mis à jour par Frédéric Péters il y a plus de 6 ans

Tu as eu ça à quel moment?

À l'exécution des tests. (manquent les init.py dans le patch)

#33

Mis à jour par Frédéric Péters il y a plus de 6 ans

À défaut de pouvoir retirer les exceptions j'ai vidé le fichier, mais alors la commande échoue avec "chrono.agendas.models.ICSError: Le fichier ne contient aucun événement.".

C'est toujours le cas, si l'ics distant est "soudainement" vide (ics valide mais aucun vevent dedans), l'actualisation ne se fait pas.

#34

Mis à jour par Serghei Mihai il y a plus de 6 ans

Ok.
Quand il n'y a aucun evenement dans l'ICS, supression des exceptions "distantes".

#35

Mis à jour par Frédéric Péters il y a plus de 6 ans

Mmm, plutôt que du code spécifiquer ne lever l'erreur que si "store_uid" n'est pas positionné. (et je me dis alors que l'intention pourrait être plus claire, que store_uid devrait être nommé genre keep_in_sync ou autre chose).

Ça permettra d'éviter la régression cachée dans les tests :

-    assert "The file doesn't contain any events." in resp.content
+    assert "0 exceptions have been imported." in resp.content
#36

Mis à jour par Serghei Mihai il y a plus de 6 ans

Patch à jour en gardant le message d'erreur quand le fichier téléchargé ne contient pas d'evenements.
Au passage, pour les evenements issus d'un ics disant la mise à jour se fait en fonction de l'uid.

#37

Mis à jour par Frédéric Péters il y a plus de 6 ans

            if keep_synced_by_uid:
                TimePeriodException.objects.filter(external_id__startswith='desk-%s:' % self.id).delete()
                return total_created

ne me semble pas nécessaire; laisser la fonction se dérouler quand keep_synced_by_uid est positionné devrait conduire au même résultat.

#38

Mis à jour par Serghei Mihai il y a plus de 6 ans

Ok.
Je voyais l'action de supression des "vieux" evenements immédiatement à la detection d'un ics vide, mais se fera de toute façon.

#39

Mis à jour par Thomas Noël il y a plus de 6 ans

  • «creation_date__lt=update_time» pas clair, il faut nommer ça update_datetime des deux côtés (ou modification_datetime)
  • ne faire le delete que if keep_synced_by_uid:
  • nouveau imports inutiles chrono/manager/forms.py
  • logger inutilisé dans sync_desks_timeperiod_exceptions.py
  • perso je pensais qu'on gagnerait le mode "sync" même pour un simple fichier ICS uploadé, c'est quand même plus "logique"
#40

Mis à jour par Serghei Mihai il y a plus de 6 ans

Attribut rénommé en update_datetime. Imports inutiles et logging supprimés.
On verra plus tard pour garder à jour les evenemets issus d'un fichier .ics chargé à la main.

#41

Mis à jour par Frédéric Péters il y a plus de 6 ans

On verra plus tard pour garder à jour les evenemets issus d'un fichier .ics chargé à la main.

S'il fallait vraiment y croire, ça passerait par un ticket.

#42

Mis à jour par Serghei Mihai il y a plus de 6 ans

C'est dans #19825.

#43

Mis à jour par Thomas Noël il y a plus de 6 ans

Il manque des desk=self lors des delete()

Et à ce sujet, incompréhension pour moi : le "desk-%s:" en prefixe ne sert à rien, le desk cible est déjà indiqué dans le modèle TimePeriodException.

#44

Mis à jour par Serghei Mihai il y a plus de 6 ans

Desk rajouté.
Le prefixe sert comme marquer d'une exception issue d'une source distante et non d'un fichier uploadé one shot.

#45

Mis à jour par Thomas Noël il y a plus de 6 ans

Serghei Mihai a écrit :

Le prefixe sert comme marquer d'une exception issue d'une source distante et non d'un fichier uploadé one shot.

Toujours pas d'accord : la présence d'un external_id suffit. Il y a quelque chose que je ne dois pas comprendre, je lis plus haut qu'on parle d'un "global:"... no comprenda.

#46

Mis à jour par Frédéric Péters il y a plus de 6 ans

Toujours pas d'accord : la présence d'un external_id suffit. Il y a quelque chose que je ne dois pas comprendre, je lis plus haut qu'on parle d'un "global:"... no comprenda.

Je vais prendre le défaut d'explication comme nécessité de commenter : moi pareil, plus haut, à un moment, je me suis posé la même question; au final, en tirant les choses par les cheveux, je pense que j'étais arrivé à rationaliser la chose ainsi : il va y avoir souhait d'exceptions globales, de plusieurs sources d'exceptions globales, et chacune serait alors à l'origine de TimePeriodException avec comme external_id "global-%d:..." % global_exception_source.id; et par mimétisme, il y avait anticipation ici et même chose employée pour les exceptions par guichet (même si formellement pas nécessaire étant donné l'attribut desk).

S'il n'y a pas d'autre explication, on peut allègrement l'ignorer et faire sans.

#47

Mis à jour par Thomas Noël il y a plus de 6 ans

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

(...) (même si formellement pas nécessaire étant donné l'attribut desk).

Ok, ça fait un peu bizarre, mais pourquoi pas.

#48

Mis à jour par Frédéric Péters il y a plus de 6 ans

(...) (même si formellement pas nécessaire étant donné l'attribut desk).

Ok, ça fait un peu bizarre, mais pourquoi pas.

À noter quand même : on peut allègrement l'ignorer et faire sans. (plutôt que se justifier les choses de manière compliquée)

#49

Mis à jour par Thomas Noël il y a plus de 6 ans

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

(...) (même si formellement pas nécessaire étant donné l'attribut desk).

Ok, ça fait un peu bizarre, mais pourquoi pas.

À noter quand même : on peut allègrement l'ignorer et faire sans. (plutôt que se justifier les choses de manière compliquée)

Alors je préférerais.

#50

Mis à jour par Serghei Mihai il y a plus de 6 ans

J'avais suivi, aveugelement, le raisonnement de Frédéric. Mais en discutant avec Thomas et suite aux commentaires je comprend que ça n'a pas vraiment de sens. Et quand le besoin de marquer les exceptions comme globales viendra on préfixera le external_id par global-.
Patch à jour avec l'external_id comportant uniquement l'uid de l'evenement.

#51

Mis à jour par Thomas Noël il y a plus de 6 ans

Raté en première lecture : la commande va crasher au premier soucis rencontré, sans tenter de mettre à jour tous les ICS distants. Il ne faut pas raiser mais logguer et passer au suivant.

external_id = models.CharField(_('External ID'), max_length=256, null=True) => ne pas utiliser null pour les charfield, mais blank=True ; d'ailleurs ensuite tu fais un exclude(external_id='')

#52

Mis à jour par Serghei Mihai il y a plus de 6 ans

J'ai utilisé une CommandError car sur une install locale au lancement de la command quand il y a un pépin ça donne en sortie

No handlers could be found for logger "chrono.manager.management.commands.sync_desks_timeperiod_exceptions" 

Mais bon, relançons la discussion du logging.
Je refais le patch avec le logging.

#53

Mis à jour par Serghei Mihai il y a plus de 6 ans

Patch à jour avec un warning loggué quand c'est pas possible de récupérer l'ics distant et external_id avec blank=True

#54

Mis à jour par Frédéric Péters il y a plus de 6 ans

Mais bon, relançons la discussion du logging.

Où ?

No handlers could be found for logger "chrono.manager.management.commands.sync_desks_timeperiod_exceptions"

Je ne vois toujours pas d'intérêt à afficher ça. En attendant, print sur stderr.

#55

Mis à jour par Serghei Mihai il y a plus de 6 ans

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

Où ?

Je ferai un ticket pour ça.

Je ne vois toujours pas d'intérêt à afficher ça. En attendant, print sur stderr.

Patch avec écriture sur stderr.

#56

Mis à jour par Thomas Noël il y a plus de 6 ans

Ajouter un \n dans le sys.stderr.write ou faire un plus classique print >> sys.stderr, ... (ou un six.print_... si on veut préparer python3, mais d'ici là on aura peut-être réussi à gérer cette affaire de log)

#57

Mis à jour par Serghei Mihai il y a plus de 6 ans

Et avec un print >> sys.stderr.
Je suis plutôt pour qu'on régle l'affaire des logs.

#58

Mis à jour par Thomas Noël il y a plus de 6 ans

TimePeriodException.objects.exclude(desk=self, external_id='').delete() : l'impression diffuse que ça va détruire pas mal de choses, non ? (j'ai toujours beaucoup beaucoup de mal avec les exclude, mais j'ai l'impression qu'il faut plutôt faire un filter(desk=self).exclude(external_id=''))

#60

Mis à jour par Thomas Noël il y a plus de 6 ans

Ça me semble poussable ainsi (même si un test avec deux desk différents aurait dû relever le bogue précédent, une couverture à 100% ça veut pas dire que tout est testé ;) ).

Si tu as encore de l'énergie : ça serait chouette lors d'un import d'avoir un décompte des creations/mise-à-jour/suppressions plutôt qu'uniquement les créations. Ca permettrait facilement à un utilisateur de valider que ses modifs ont été prises en compte, en venant manuellement cliquer sur l'interface.

#61

Mis à jour par Serghei Mihai il y a plus de 6 ans

  • Statut changé de En cours à Résolu (à déployer)

Discuté avec Thomas par jabber. C'est un ack.

Pour afficher le nombre de mises à jour et suppressions: #19870

commit 71f5b91cbe4b3abeab54432829c0a9162b50c189 (HEAD -> master, origin/master, origin/HEAD)
Author: Serghei Mihai <smihai@entrouvert.com>
Date:   Tue Oct 3 23:15:00 2017 +0200

    agenda: add support for remote calendar file with exceptions (#19070)

    Remote calendars can be specified by desk and updated hourly, or used once.

#62

Mis à jour par Serghei Mihai il y a plus de 6 ans

  • Statut changé de Résolu (à déployer) à Fermé

Formats disponibles : Atom PDF