Projet

Général

Profil

Development #21626

Interface de visualisation/correction sur les erreurs de notification de paiement

Ajouté par Frédéric Péters il y a environ 6 ans. Mis à jour il y a plus de 4 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
04 février 2018
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

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

Révisions associées

Révision 964d0a87 (diff)
Ajouté par Lauréline Guérin il y a plus de 4 ans

lingo: new page to display payments in error (#21626)

Révision 2920cf5d (diff)
Ajouté par Lauréline Guérin il y a plus de 4 ans

lingo: add search field (#21626)

Révision ea11c7f0 (diff)
Ajouté par Lauréline Guérin il y a plus de 4 ans

lingo: action mark_as_notified (#21626)

Historique

#1

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
#2

Mis à jour par Lauréline Guérin il y a plus de 4 ans

  • Assigné à mis à Lauréline Guérin
#3

Mis à jour par Frédéric Péters il y a plus de 4 ans

  • Description mis à jour (diff)
#4

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

#6

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)

#7

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.

#8

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

#9

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.

#10

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.

#11

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 ?

#12

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.

#13

Mis à jour par Lauréline Guérin il y a plus de 4 ans

- 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

#14

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.

#15

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)
#16

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

Formats disponibles : Atom PDF