Development #21626
Interface de visualisation/correction sur les erreurs de notification de paiement
0%
Description
Combo reçoit notif de paiement, là-dessus tape sur un wcs où un saut sur déclencheur doit attendre, mais il arrive là qu'il y ait eu erreur dans le workflow et absence de telle action. Pour réparer ça il faut alors regarder dans la db, les éléments de panier payés mais pas notifiés, vérifier le statut côté wcs, etc.
Il faudrait une interface affichant ces éléments et permettant à l'admin de les marquer comme (im)payés.
De l'écran "Paiement en ligne" (qui affiche les transactions), on aurait un lien vers un nouvel écran (bouton "Paiements en erreur" ou autre libellé), dans ce nouvel écran on aurait un tableau basé sur BasketItem, qui reprendrait libellé/lien, montant, date de paiement ou d'annulation, + lien vers la transaction associée (simplement un lien vers /lingo/?q=identifiant de transaction, ça doit être unique), avec les BasketItem qui ont un payment_date mais pas de notification_date, + les BasketItem qui ont une transaction avec un status d'erreur (eopayment.ERROR, 99).
Sur les lignes, également, des boutons pour "rejouer la notification", "marquer comme payé", "marquer comme impayé".
Et au-dessus de ça un champ recherche qui permettrait de filter le tableau sur base du libellé (BasketItem.object), pour permettre ainsi de taper 156-501 et afficher le paiement correspondant.
(j'imaginais aussi avoir les BasketItem pour lesquels il y a eu demande d'annulation et où ça a échoué mais avec ce qu'on a en base actuellement ça ne me semble pas possible).
Fichiers
Historique
Mis à jour par Frédéric Péters il y a environ 6 ans
- Sujet changé de Interface de visualisation/correction sur les erreurs de notification à Interface de visualisation/correction sur les erreurs de notification de paiement
Mis à jour par Lauréline Guérin il y a plus de 4 ans
Après discussion, on a décidé de partir sur:
- liste des basketitems qui sont soit avec une date de paiement, mais sans date de notification, soit dont la dernière transaction est en erreur
- avec un lien vers la démarche wcs, et un lien vers la transaction (/lingo/?q=identifiant de transaction)
- seule action possible dans un premier temps: pour les items sans notification, les marquer comme notifiés
on itèrera dans d'autres tickets par la suite, en fonction des besoins
Mis à jour par Lauréline Guérin il y a plus de 4 ans
- Fichier 0003-lingo-action-mark_as_notified-21626.patch 0003-lingo-action-mark_as_notified-21626.patch ajouté
- Fichier 0002-lingo-add-search-field-21626.patch 0002-lingo-add-search-field-21626.patch ajouté
- Fichier 0001-lingo-new-page-to-display-payments-in-error-21626.patch 0001-lingo-new-page-to-display-payments-in-error-21626.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Thomas Noël il y a plus de 4 ans
Juste un début de lecture (je suis jamais bien à l'aise sur les RawSQL et autre union ou annotate)
Sur :
payment_date__lt=now() - datetime.timedelta(minutes=300)
est-ce que ça signifie qu'on afficherait uniquement les paiements échoués sur les 5 dernières heures ? Car je pense qu'il faut aller beaucoup plus loin que ça (typiquement les usagers viennent se plaindre de soucis quelques jours/semaines après)
(à part ça, qu'est-ce que tu te débrouilles bien avec les ClassBasedViews, dis donc !) (ah ah ah) (private joke)
Mis à jour par Frédéric Péters il y a plus de 4 ans
(je n'ai pas lu les patchs), payment_date__lt=now() - datetime.timedelta(minutes=300)
, je pense ça doit juste plutôt être gt, l'idée étant que pendant tout ce temps (300 minutes) il y des tentatives de notification asynchrones (lingo/__init.py, notify_payments), que c'est uniquement après qu'on peut formellement se dire que ça ne va vraiment pas passer.
Mis à jour par Lauréline Guérin il y a plus de 4 ans
Non c'est bien ça: la date de paiement doit être plus petite que maintenant - 5H :)
https://dev.entrouvert.org/projects/combo/repository/revisions/master/entry/combo/apps/lingo/__init__.py#L60 => On retry pendant 5H
payment_date__lt=now() - datetime.timedelta(minutes=300) => passé ces 5H de retry, on remonte les paiements en erreur
Mis à jour par Frédéric Péters il y a plus de 4 ans
c'est bien ça: la date de paiement doit être plus petite que maintenant - 5H :)
Tout à fait :) et voilà j'ai testé,
Il faudrait ne pas reprendre dans la liste les BasketItem qui ont regie__webservice_url définit; ces objets sont créés (lingo/models.py, notify_remote_items_of_payments), après notification, sans que leur notification_date ne soit complété. Ou alors, parce que je pense que cet attribut pourrait être posé et que ce serait plus clean ainsi, ajouter une migration qui prenne ces BasketItem et y fasse notification_date=payment_date).
S'il n'y a pas de source_url, on peut zapper le lien "mark as notified", qui ne fonctionnera pas.
Pour les transactiosn en erreur (queryset2), le lien vers la transaction va renvoyer un tableau vide, parce qu'on a status__in=(eopayment.PAID, eopayment.ACCEPTED)) dans TransactionListView::get_queryset. Je serais là pour modifier ce get_queryset pour faire :
qs = Transaction.objects.exclude(status__in=(eopayment.WAITING, EXPIRED)).order_by('-start_date') if not query: # no query, display paid/accepted transactions qs = qs.filter(status_in=(eopayment.PAID, eopayment.ACCEPTED)) else: # filter on query ... et ici pas de filtre status_in
Et mini-détail, "This site doesn't have any payment in error yet.", j'en retirerais le "yet", sur l'idée qu'on espère bien ne pas en avoir.
Mis à jour par Thomas Noël il y a plus de 4 ans
Autre détail pour ma part : indiquer quelque part sur l'UI qu'il y a filtrage des 5 dernières heures.
Mis à jour par Lauréline Guérin il y a plus de 4 ans
Pour les transactiosn en erreur (queryset2), le lien vers la transaction va renvoyer un tableau vide
Je n'ai affiché le lien que pour les items qui ont un statut différent de ERROR, tu veux que j'affiche le lien tout le temps et que je change le queryset du listing du coup ?
Mis à jour par Frédéric Péters il y a plus de 4 ans
Je n'ai affiché le lien que pour les items qui ont un statut différent de ERROR, tu veux que j'affiche le lien tout le temps et que je change le queryset du listing du coup ?
C'est sans doute dans ma production artificielle de lignes en erreur en local, je me suis retrouvé avec un lien vers une transaction et le tableau qui n'affichait rien; laissons ça de côté, on verra plus tard pour étendre la vue des transactions avec une colonne "statut", pour pouvoir faire des liens vers des transactions en erreur.
Mis à jour par Lauréline Guérin il y a plus de 4 ans
- Fichier 0003-lingo-action-mark_as_notified-21626.patch 0003-lingo-action-mark_as_notified-21626.patch ajouté
- Fichier 0002-lingo-add-search-field-21626.patch 0002-lingo-add-search-field-21626.patch ajouté
- Fichier 0001-lingo-new-page-to-display-payments-in-error-21626.patch 0001-lingo-new-page-to-display-payments-in-error-21626.patch ajouté
- yet enlevé
- le lien vers source_url n'est pas affiché si source_url n'est pas défini
- le lien "marquer comme notifié" n'est pas affiché si source_url n'est pas défini
- les items dont la regie ont un webservice_url sont exclus du listing
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Solution proposée à Solution validée
Hop, go.
Mis à jour par Lauréline Guérin il y a plus de 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit ea11c7f03e8398bb928f07cd6227109ff9787024 Author: Lauréline Guérin <zebuline@entrouvert.com> Date: Mon Dec 2 10:25:03 2019 +0100 lingo: action mark_as_notified (#21626) commit 2920cf5d79a403f67992fdb582412015d0a62475 Author: Lauréline Guérin <zebuline@entrouvert.com> Date: Fri Nov 29 16:03:07 2019 +0100 lingo: add search field (#21626) commit 964d0a87aad2ac57fdab77e84783ca7044ec3277 Author: Lauréline Guérin <zebuline@entrouvert.com> Date: Fri Nov 29 15:35:09 2019 +0100 lingo: new page to display payments in error (#21626)
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
lingo: new page to display payments in error (#21626)