Produits Entr'ouvert » Chrono

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

comme le workflow de paiement gère un trigger "paid"

Et le code qui permet de signer une telle requête vers w.c.s. est dans combo, je pense que c'est la seule brique qui avait ce besoin. Je le bouge dans hobo, et je l'importe avec le try/except qui va bien pour ne pas introduire de dépendance trop forte ?

Une copie de plus (il est déjà aussi dans hobo et passerelle).

Sur 0001 : copie aussi les tests... question de couverture, et puis parce que les tests c'est bien. Et modifie aussi les copyrights (combo->chrono, 2018->2020)

Sur 0002 : je dirais qu'il faut d'abord tenter le POST sur l'URL et si ça ne répond pas OK afficher un message qui indique le pépin et demande une sur-validation pour vraiment supprimer.

Thomas Noël a écrit :

Sur 0002 : je dirais qu'il faut d'abord tenter le POST sur l'URL et si ça ne répond pas OK afficher un message qui indique le pépin et demande une sur-validation pour vraiment supprimer.

OK pour rattraper le raise_for_status dans la vue et afficher autre chose qu'une 500, par contre je n'arrive pas à imaginer un parcours intelligible de sur-validation. Tu cliques, on te dit que ça marche pas, et que tu peux recliquer. Mais est-ce que le reclic tente quand même à nouveau l'appel ws ? Donc à la fin peut-être que ça a marché, peut-être pas ? Ou est-ce qu'il ne retente pas, à ce moment là il faut dire à l'agent « si tu veux retenter, ne reclique pas, rafraichit la page »...

(et puis ça fait sortir le code des sentiers battus, il faut mettre un flag en session ou fortement triturer le formulaire, bref je serais pour ne pas permettre l'annulation si l'appel foire, de toute façon il faudra faire une action globale qui rattrape le coup pour mettre dans le statut annulé côté demande, l'appel à l'API cancel de chrono pourra se faire là)

Valentin Deniaud a écrit :

OK pour rattraper le raise_for_status dans la vue et afficher autre chose qu'une 500, par contre je n'arrive pas à imaginer un parcours intelligible de sur-validation. (...)

Dans mes faibles connaissance Django ça se gère via le form_valid qui va tenter le POST et déclarer un form_invalid si ça ne marche pas, et dans ce cas on réaffiche le form avec une case à cocher "supprimer de toute façon" ...?

(et puis ça fait sortir le code des sentiers battus, il faut mettre un flag en session ou fortement triturer le formulaire, bref je serais pour ne pas permettre l'annulation si l'appel foire, de toute façon il faudra faire une action globale qui rattrape le coup pour mettre dans le statut annulé côté demande, l'appel à l'API cancel de chrono pourra se faire là)

Le problème classique sera que la démarche correspondante n'existe plus, donc, non, faut pouvoir "forcer".

Valentin Deniaud a écrit :

• Si l'URL pour rappeler wcs n'a pas été passée à la réservation, j'affiche un warning sur la page de confirmation de l'annulation. Problème gadjo là encore, le div warningnotice ne s'affiche pas dans la popup (ok en pleine page), il faut trouver quelque chose d'autre ou patcher gadjo.

Trouvé la parade, il faut mettre le div à l'intérieur de la balise form.

Pour l'instant il est nécessaire d'être manager de l'agenda pour pouvoir supprimer des résas, à voir si ça ne correspond pas mieux aux usages d'autoriser aussi le rôle de visualisation

Je viens de me poser la question et je pense que ce serait plus adapté de permettre ça aux agents qui peuvent consulter l'agenda (le "manage" étant plutôt de l'ordre de la gestion du paramétrage de l'agenda).

Si l'URL pour rappeler wcs n'a pas été passée à la réservation, j'affiche un warning sur la page de confirmation de l'annulation.

Sur ce point j'hésite pas mal mais je serais presque à ne pas permettre l'annulation depuis chrono s'il y a backoffice_url mais pas cancel_callback_url, sous-entendu ça se gère depuis la démarche, dans la popup afficher que ça se gère depuis la demande avec en lien backoffice_url.