Produits Entr'ouvert » Combo

Mais il y a normalement déjà une information communiquée à l'usager,

        except PaymentException as e:
            messages.error(request, _('We are sorry but the payment service '
                                      'failed to provide a correct answer.'))
            return HttpResponseRedirect(get_basket_url())

Ça ne fonctionne pas ?

Ou c'est idée qu'en complément, il y ait cette interface avec le workflow ?

Parce que je vois quand même un danger avec :

basculer sur des statut 'Paiement en erreur'

sur une erreur, le panier n'est pas vidé, et l'usager peut même immédiatement retenter l'affaire, il me semble; après la bascule de la demande sur 'Paiement en erreur', le workflow devrait demander la suppression du panier ?

Il y aussi un truc pas clair pour moi dans cette équivalence 1 paiement = 1 demande qui est posée ici, qui n'est pas la réalité du panier. 

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

Mais il y a normalement déjà une information communiquée à l'usager,

[...]

Ça ne fonctionne pas ?

Ce n'est pas le même cas, je parle du cas où payzen nous dit proprement que la transaction est en erreur, et où on a intégré proprement cette information via CallbackView.

Ou c'est idée qu'en complément, il y ait cette interface avec le workflow ?

Oui.

Il y a sûrement des trucs que je loupe (pas simple de comprendre à la lecture de la doc et du code), mais je vais essayer de mieux planter le décor.

Le workflow dont je parle est ici https://demarches-venissieux-test.demarches.sitiv.fr/reservation-de-salle/planitech-demo/
(c'est WIP, choisir la salle foyer sambat pour tester).

Sur la lancée de #25725 et incité par Stéphane, je me suis lancé dans un workflow de paiement
où l'usager ne passe pas par la vue panier avant d'arriver chez payzen.
Sur cette lancée je me suis dit, comme un cowboy, qu'on devait pourvoir goupiller un workflow où l'utilisateur ne voit jamais le panier,
même en cas de soucis, c'est peut-être mon pêché originel.

Je teste le machin et ça semble satisfaisant quand les paiements sont acceptés.

Je teste un cas d'erreur, arrivé dans payzen je choisis une des options de paiement refusé,
déclenche le paiement qui est naturellement refusé, clique sur le bouton 'Annuler et retourner à la boutique',
et retombe sur ma demande, en statut 'En attente de paiement'.

Et c'est vrai que la demande est toujours en attente de paiement.
Mais l'information que la transaction a été refusée est arrivée jusqu'à nous via la vue callback de lingo,
la transaction de notre coté est bien en erreur.

Tel que mon workflow est foutu, le statut 'En attente de paiement' peut être atteint en cas de transaction en erreur,
en cas de paiement effectué mais lingo pas encore notifié par payzen (peut-être que ce cas est marginal), en cas de je suis arrivé sur payzen j'ai rien fait et j'ai repris ma demande plus tard (d'ailleurs est-ce que payzen finit par nous envoyer quelque chose en callback au bout d'un moment dans ce cas, une expiration ? je ne sais pas).

Donc pouvoir discriminer au moins un de ces cas par un statut de wokflow spécifique m'a semblé la marche à suivre, pour afficher un message circonstancié à l'usager, pour lui proposer de re-essayer de payer plutôt que de payer tout court ...

Thomas me dit que je me prends le choux sur des cas marginaux.

où l'usager ne passe pas par la vue panier avant d'arriver chez payzen.

Voilà, faut s'arrêter à ça et prendre ce besoin et le gérer correctement (travail à définir), parce que là je pense on entasse des trucs pour contourner le panier, pas bon.

+1, vous ne pouvez pas utiliser BasketItemPayView pour rediriger ensuite sur une URL hors de combo, toute la logique des paiements pose des messages qui ne seront visibles que dans combo, donc au minimum il faut gérer les redirections au niveau de handle_payment() et ReturnView avec de vrais vues et un bon bouton "Continuer" dans le cas où des messages sont disponibles (ce que fait le DisplayMessageBeforeRedirectMiddleware de façon globale dans authentic, voir src/authentic2/middleware.py).

Une autre possibilité c'est de recopier les messages disponibles dans un paramètre de l'URL de retour, mais faut penser à les afficher au retour.

Benjamin Dauvergne a écrit :

Une autre possibilité c'est de recopier les messages disponibles dans un paramètre de l'URL de retour, mais faut penser à les afficher au retour.

Et ne le faire que si l'origine du site et de l'URL de retour diffèrent.

Emmanuel Cazenave a écrit :

Thomas me dit que je me prends le choux sur des cas marginaux.

Il a tort, c'est juste que vous faites n'importe quoi dans lingo. BasketItemPayView était une mauvaise idée, à mon avis, il aurait fallu collecter les besoins, analyser, tout ça :)

Je ne pense pas nécessaire de s'engouffrer dans un truc qui n'est pas mesuré, du recul d'abord; bref "collecter les besoins, analyser, tout ça".

J'aimerais rejeter ce ticket, qu'on puisse prendre le temps d'un plan dans #32249.

Go.