Produits Entr'ouvert » Chrono

si tu fais du get_or_create pour le guichet unique, pourquoi faire une migration ?

j'ai créé le ticket #50672 - en fonction de la réponse apportée il peut être inutile dans manager_events_agenda_settings.html de proposer l'édition ou la suppression d'une exception (elles seront toutes read_only)

Quel impact si on configure un event récurrent (disons tous les lundi) avec une date de fin de récurrence (les events sont créés en DB); puis on ajoute des exceptions. Que se passe-t-il pour les events déjà en DB, si certains sont impactés par une des exceptions ajoutées ?

note: tu as géré l'import/export de ce guichet unique et de ses exceptions/sources/unavaibility ?
actuellement (main) on n'importe les desks que si kind == meetings

Valentin Deniaud a écrit :

Il reste quand même les exceptions ajoutées manuellement qui devront être éditables/supprimables, non ?

J'avais cru lire que tu ne gérais pas les exceptions manuelles ? Que tu disais qu'il suffisait d'annuler l'événement ?

Emmanuel Cazenave a écrit :

Valentin Deniaud a écrit :

je pense qu'on peut se contenter d'aller annuler l'évènement en question.

Mais comment je fais ça pour un évènement sur lequel il n'y pas eu de réservation et donc pas persistant en DB et donc visible nulle part (si j'ai bien suivi) ?

Tu as fait tourner la branche ? Il n'y a aucune différence entre une récurrence persistante en DB ou pas, les deux sont bien entendu visibles, les deux sont annulables de manière transparente (et sous le capot si on va pour annuler un évènement qui n'était pas en DB, il va être créé automatiquement dans le processus, mais c'est un détail technique pas très gênant et tout à fait invisible).

Lauréline Guerin a écrit :

Valentin Deniaud a écrit :

Il reste quand même les exceptions ajoutées manuellement qui devront être éditables/supprimables, non ?

J'avais cru lire que tu ne gérais pas les exceptions manuelles ? Que tu disais qu'il suffisait d'annuler l'événement ?

Pas vraiment, je disais que fonctionnellement ça aura plus de sens d'aller annuler la récurrence du 4 janvier plutôt que de mettre une exception le 4 janvier, par contre si il faut annuler toute une semaine c'est sûrement pratique de pouvoir poser une exception (et au niveau code c'est un bouton en plus, donc je me suis dit que ça mangeait pas de pain).
Ça m'irait de ne pas avoir ça ceci dit, ça pousserait vers l'utilisation systématique des calendriers d'indispo et c'est peut-être une bonne chose.

Valentin Deniaud a écrit :

Lauréline Guerin a écrit :

Quel impact si on configure un event récurrent (disons tous les lundi) avec une date de fin de récurrence (les events sont créés en DB); puis on ajoute des exceptions. Que se passe-t-il pour les events déjà en DB, si certains sont impactés par une des exceptions ajoutées ?

Pas encore géré mais c'est tout à fait nécessaire à faire dans ce ticket. J'imagine que dans ce cas là on va supprimer les évènements, avec une erreur si il y a des réservations. Et aussi dans l'autre sens, enlever l'exception doit créer l'évènement.

Ça se fait bien, par contre tout le problème c'est

; puis on ajoute des exceptions.

Il n'y a pas de point d'entrée qui regroupe ajout/modif/suppression d'une exception, il y a d'un côté ce qui est faisable depuis la page de settings d'un agenda, depuis la page de config d'un calendrier d'indispo, et tous les imports d'exceptions asynchrones depuis ICS ou jours fériés.
Ça ne me semble pas jouable d'aller toucher tous ces endroits, ma seule idée pour l'instant c'est de jouer cette mise à jour des évènements également en asynchrone, ça permettrait de tourner sur tous les agendas sans devoir s'occuper de savoir si une exception a été modifiée.

Rebasé.

if created and self.kind == 'events':
    desk = Desk.objects.create(agenda=self, slug='_exceptions_holder')
    desk.import_timeperiod_exceptions_from_settings()

Ça met un desk sur et potentiellement des exceptions sur touts les agendas évènements, y compris ceux qui ont rien demandé en termes de récurrence/exceptions. J'imagine que tu as pris soin que ça ne mette pas la brouille dans ces les évènements exposés par des agendas évènements "standard" mais un test unitaire pour assurer la chose me paraîtrait bien.

Au passage ya pas non plus de test d'API qui vérifie qu'un évènement récurrent ne sort plus s'il est masqué par une exception (j'imagine que tu fais confiance à ce qui se passe dans tests_agendas.py mais un test au niveau supérieur/final c'est bien bien quand même).

Sur 0003 prefetch, la conjonction de l'intention d'optimiser et de ce qui suit fait bizarre, peut-être expliquer ou rendre le test plus proche d'une situation réelle :

- assert len(ctx.captured_queries) == 6
+ assert len(ctx.captured_queries) == 7

Emmanuel Cazenave a écrit :

Ça met un desk sur et potentiellement des exceptions sur touts les agendas évènements, y compris ceux qui ont rien demandé en termes de récurrence/exceptions. J'imagine que tu as pris soin que ça ne mette pas la brouille dans ces les évènements exposés par des agendas évènements "standard" mais un test unitaire pour assurer la chose me paraîtrait bien.

Comme le code que tu pointes est dans la méthode save(), il tourne déjà sur tous les évènements créés par les tests, et visiblement ils passent :)

Mais j'en profite pour souligner que ces exceptions n'ont d'effet que sur les évènements récurrents : on peut toujours ajouter un évènement normal sur une période d'exception sans que ça pose de problème.

OK pour le reste, je vais compléter les tests (et si tu veux à pousser en même temps il y aura aussi le petit #52115).