Produits Entr'ouvert » Chrono

(peut-être commencer par #44159)

C'est plutôt WIP, je vais attendre que #44159 soit bon pour finir.

Yep finissons l'autre d'abord.

En passant, quid de l'action inverse, « désannuler » un évènement ?

Je dirais que non ne considérons pas ça.

Je pense ça ne va pas tenir de faire la même chose, on va trop rapidement arriver à des événements avec trop de réservations pour gérer ça de manière synchrone; pour moi ça doit du coup se passer en deux temps, genre un attribut supplémentaire "en cours d'annulation" et passer dessus lors d'un cron. Et clairement ça empêche la gestion d'erreur fine, j'imagine que le seul truc possible c'est produire un rapport d'annulation, qui serait annoncé en haut de la page de l'événement s'il y a eu des erreurs.

Je peux faire ça, mais avoir un endpoint /jump/ générique auquel on puisse balancer le nom du trigger et les identifiants des demandes ça ne serait pas plus simple et mieux sur le long terme ?

Je peux faire ça, mais avoir un endpoint /jump/ générique auquel on puisse balancer le nom du trigger et les identifiants des demandes ça ne serait pas plus simple et mieux sur le long terme ?

Il y a un peu ça avec les actions de masse mais ça ne change pas tellement l'affaire, un appel ou 150 appels, ça doit de toute façon être asynchrone.

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

Je peux faire ça, mais avoir un endpoint /jump/ générique auquel on puisse balancer le nom du trigger et les identifiants des demandes ça ne serait pas plus simple et mieux sur le long terme ?

Il y a un peu ça avec les actions de masse mais ça ne change pas tellement l'affaire, un appel ou 150 appels, ça doit de toute façon être asynchrone.

OK, je me disais que temps d'un appel << temps de 150 appels, et qu'on pouvait rester sur du synchrone comme pour l'annulation d'une réservation.

Là j'ai peur que ça soit peu agréable d'utilisation, vouloir annuler un évènement puis devoir attendre x minutes pour savoir ce qu'il en est finalement, avec rien de mieux à faire que de rafraîchir la page. Pour améliorer ça peut-être envoyer une notification par mail à l'annulateur quand la suppression est terminée, avec les éventuelles erreurs rencontrées ?

Ça risque également d'être très pénible dès lors qu'il y a des erreurs. Dans le cas où un wf est mal configuré et que l'appel au trigger échoue, il faut clairement alerter et aller agir là-bas. Par contre quand l'échec vient d'un formulaire qui n'existe plus, peut-être le cas majoritaire, ça pourrait être ignoré ? Je crois qu'en l'état actuel des choses le retour de l'API ne permet pas de distinguer les deux, à vérifier.

        for event in Event.objects.filter(cancellation_scheduled=True):

Je récupérerais les events, les marquerait cancellation_scheduled=False, puis ferais le reste; dans l'idée qu'un cron un peu long ne vienne pas rejouer la même chose.

Un autre problème des appels multiples à l'API que je n'avais pas noté c'est qu'on a pas d'atomicité, on peut se retrouver à annuler une partie des réservations associées à l'évènement avant d'avoir une erreur. Tant qu'à faire donc, j'ai pris le parti d'essayer d'annuler tout ce qui peut l'être, c'est à dire de ne pas s'arrêter au premier échec.

Oui, très bien, on n'a pas à s'arrêter parce qu'une réservation pose problème.

    font-weight: bold;

n'est pas indentée comme les autres.

{% blocktrans }The {{ bookings_count }} related bookings will also be cancelled.{ endblocktrans %}

et

({% blocktrans with count=report.bookings.count }{{ count }} failures{ endblocktrans %})

et peut-être d'autres aussi.

Gérer {% plural %}

Je pense qu'il n'est pas vraiment utile de garder les rapports d'erreur en base de donnée ad vitam eternam, est-ce que j'ajoute quelque chose dans la commande pour les supprimer après un mois ?

Yep.