Development #40244
Rattraper les exceptions levées par backend.request()
0%
Description
La plupart du temps cette méthode est safe, mais dans des backends qui utilisent des webservices on doit parfois lever des exceptions.
Fichiers
Révisions associées
lingo: handle exceptions raised by backend.request (#40244)
lingo: handle exceptions raised by backend.request (#40244)
lingo: handle exceptions raised by backend.request (#40244)
lingo: handle exceptions raised by backend.request (#40244)
Historique
Mis à jour par Valentin Deniaud il y a environ 4 ans
- Fichier 0001-lingo-handle-exceptions-raised-by-backend.request-40.patch 0001-lingo-handle-exceptions-raised-by-backend.request-40.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Il y a eopayment.common.RequestException qui est un peu moche, idéalement il faudrait un mini commit dans eopayment pour pouvoir se passer du common.
Mis à jour par Emmanuel Cazenave il y a environ 4 ans
Valentin Deniaud a écrit :
Il y a
eopayment.common.RequestExceptionqui est un peu moche, idéalement il faudrait un mini commit dans eopayment pour pouvoir se passer du common.
Je suis d'accord et d'avis de faire ce commit là bas avant de patcher ici.
Et même si c'est bête comme chou, un petit test ici me semblerait pas mal.
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
Il faut éviter les erreurs HTTP sur des vues utilisateurs, c'est toujours mieux d'afficher un message et de permettre à l'utilisateur de revenir à un endroit où on peut retenter le paiement (et il y a déjà une vue pour ça normalement dans lingo).
Mis à jour par Emmanuel Cazenave il y a environ 4 ans
C'est vrai ça, c'est fait un peu plus haut assez dégueulassement par mes soins:
messages.warning(request, _(u'Minimal payment amount is %s €.') % regie.payment_min_amount) return HttpResponseRedirect(get_payment_status_view(next_url=items[0].source_url))
Mais plus proprement ici un
messages.warning(request, _("un message intelligent"))
return HttpResponseRedirect(get_payment_status_view(next_url=next_url))
devrait faire l'affaire, à tester quand même.
Mis à jour par Valentin Deniaud il y a environ 4 ans
- Fichier 0001-lingo-handle-exceptions-raised-by-backend.request-40.patch 0001-lingo-handle-exceptions-raised-by-backend.request-40.patch ajouté
Sans l'erreur HTTP et avec un test. Par contre il ne va pas passer tant que #40353 côté eopayment n'est pas déployé, je pense.
Mis à jour par Frédéric Péters il y a environ 4 ans
Oui, et il faut modifier setup.py et debian/control pour mentionner la nouvelle version minimale pour eopayment.
Mis à jour par Valentin Deniaud il y a environ 4 ans
- Fichier 0001-lingo-handle-exceptions-raised-by-backend.request-40.patch 0001-lingo-handle-exceptions-raised-by-backend.request-40.patch ajouté
Done.
Mis à jour par Valentin Deniaud il y a environ 4 ans
Je l'avais oublié, mais à lire le code, la pratique de rediriger vers next_url directos dans PayView est largement majoritaire, et me semble être la bonne. La manière dont sont affichées les erreurs sur la page de statut et le parcours que donne get_payment_status_view me paraissent bizarres, et là en l’occurrence j'ai surtout envie de revenir appuyer quelques coups sur le bouton de paiement voir si ça finit par marcher, donc autant ne pas me faire passer par trois pages intermédiaires.
Mis à jour par Emmanuel Cazenave il y a environ 4 ans
Valentin Deniaud a écrit :
Je l'avais oublié, mais à lire le code, la pratique de rediriger vers next_url directos dans PayView est largement majoritaire
Parce que la page de 'statut de paiement' est récente et il y a peut-être des encore des trous dans la raquette mais c'est vers ça qu'on veut aller.
La manière dont sont affichées les erreurs sur la page de statut et le parcours que donne get_payment_status_view me paraissent bizarres
C'est sûrement perfectible, faisons des tickets.
et là en l’occurrence j'ai surtout envie de revenir appuyer quelques coups sur le bouton de paiement voir si ça finit par marcher
C'est un peu emmêlé ces histoires de next_url mais de de mémoire selon comment auront été fait les appels d'ajouts d'item au panier, tu vas te retrouver soit directement sur la démarche sans aucune info sur ce qui s'est passé, soit sur la page du panier où le commun des mortels est perdu (#36469#note-1), soit sur la page d'accueil de combo en pleine pampa.
Mis à jour par Valentin Deniaud il y a environ 4 ans
- Fichier 0001-lingo-handle-exceptions-raised-by-backend.request-40.patch 0001-lingo-handle-exceptions-raised-by-backend.request-40.patch ajouté
Je teste depuis une cellule combo où next_url fait revenir sur la cellule, mais j'entends qu'il y existe d'autres cas où la redirection soit moins opportune, allons-y pour get_payment_status_view.
Mis à jour par Valentin Deniaud il y a environ 4 ans
- Fichier 0001-lingo-handle-exceptions-raised-by-backend.request-40.patch 0001-lingo-handle-exceptions-raised-by-backend.request-40.patch ajouté
(avec update des tests)
Mis à jour par Emmanuel Cazenave il y a environ 4 ans
- Statut changé de Solution proposée à Solution validée
Valentin Deniaud a écrit :
Je teste depuis une cellule combo où next_url fait revenir sur la cellule
C'est clairement un cas que je n'avais pas du tout en tête en faisant le patch qui a introduit get_payment_status_view, n'hésite pas remonter les problèmes que ça pourrait poser dans ce cas d'usage.
Mis à jour par Valentin Deniaud il y a environ 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 271e13b6803401fbddd0c2a1b67f917a0ca03cd4
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date: Thu Feb 27 17:22:56 2020 +0100
lingo: handle exceptions raised by backend.request (#40244)
Mis à jour par Frédéric Péters il y a environ 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
lingo: handle exceptions raised by backend.request (#40244)