Projet

Général

Profil

Development #58210

ne pas permettre le paiement si la demande correspondante n'existe plus

Ajouté par Thomas Noël il y a plus de 2 ans. Mis à jour il y a environ 2 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
26 octobre 2021
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

Cf le cas #58194 : des BasketItem existent qui pointent en fait vers une démarche qui a été un peu trop violemment supprimée. Ca peut arriver... on peut aussi imaginer une démarche dont on changerait le slug...

Dans ce cas, le paiement va être possible mais il ne va rien se passer ensuite.

Il faudrait plutôt ne pas autoriser le paiement quand BasketItem.source_url n'existe plus, et afficher un message à l'usager dans ce cas ("Il semble que la demande concernant cet élément a été supprimée bla bla bla").

Evidement se pose la question de savoir quelle API utiliser pour savoir si la demande existe encore, à creuser un poil, mais en mode signature intra-publik un simple GET sur source_url par combo pourrait suffire (?)


Fichiers


Demandes liées

Lié à w.c.s. - Development #58226: faire qu'un GET sur un trigger renvoie un 404 s'il n'existe pasFermé27 octobre 2021

Actions

Révisions associées

Révision 6b1f7d1d (diff)
Ajouté par Thomas Noël il y a environ 2 ans

lingo: refuse payment if an item cannot be trigged (#58210)

Historique

#2

Mis à jour par Serghei Mihai il y a plus de 2 ans

Thomas Noël a écrit :

Il faudrait plutôt ne pas autoriser le paiement quand BasketItem.source_url n'existe plus, et afficher un message à l'usager dans ce cas ("Il semble que la demande concernant cet élément a été supprimée bla bla bla").

Je dirais même qu'après l'affichage de ce message il faut proposer à l'usager d'annuler le montant à payer, sans chercher à notifier la demande associée (notify_payment(notify_origin=False))

#3

Mis à jour par Thomas Noël il y a plus de 2 ans

Serghei Mihai a écrit :

Thomas Noël a écrit :

Il faudrait plutôt ne pas autoriser le paiement quand BasketItem.source_url n'existe plus, et afficher un message à l'usager dans ce cas ("Il semble que la demande concernant cet élément a été supprimée bla bla bla").

Je dirais même qu'après l'affichage de ce message il faut proposer à l'usager d'annuler le montant à payer, sans chercher à notifier la demande associée (notify_payment(notify_origin=False))

En fait ce matin je me disais qu'on pourrait afficher l'affaire directement dans le panier, y signifier que tel item n'est plus payable, et la raison ("demande liée introuvable, bla bla"). Mais j'éviterais d'annuler le paiement (ou de proposer de le faire) : on peut parfaitement imaginer qu'un admin fonctionnel a renommé un slug sans se rendre compte de l'impact, et décide de revenir en arrière pour rétablir la situation.

Pour moi ça doit rester une situation anormale, je cherche juste ici à éviter des paiements "dans le vide" (cf #58194) complexes à gérer par le régisseur (remboursement).

#4

Mis à jour par Thomas Noël il y a plus de 2 ans

  • Lié à Development #58226: faire qu'un GET sur un trigger renvoie un 404 s'il n'existe pas ajouté
#5

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

Thomas Noël a écrit :

Pour moi ça doit rester une situation anormale, je cherche juste ici à éviter des paiements "dans le vide" (cf #58194) complexes à gérer par le régisseur (remboursement).

+1, je suis de plus en plus frileux quand on fait des .delete().

#6

Mis à jour par Serghei Mihai il y a plus de 2 ans

On a 2 moments ou on peut faire ça:

  • on n'affiche pas l'item à payer dans le panier si un GET (signé) vers source_url retourne autre chose que du HTTP 200
  • au moment du paiement, car l'URL de paiement aurait pu être envoyé à l'usager par mail, qui l'a transféré à qqun d'autre (maman qui dit à papa de payer). Et ici quel message afficher: "Erreur de paiement"? ou retourner une 404 ?
#7

Mis à jour par Thomas Noël il y a plus de 2 ans

Serghei Mihai a écrit :

On a 2 moments ou on peut faire ça:
  • on n'affiche pas l'item à payer dans le panier si un GET (signé) vers source_url retourne autre chose que du HTTP 200

Non, mon idée est plutôt de faire un GET sur l'URL du trigger paid et de voir que ça ne répond pas 404.

Mais en fait dans un premier temps je propose de se restreindre au sujet du ticket : l'interdiction de payer. Je préfère que tous les éléments du panier s'affichent, et qu'on fasse un blocage ensuite. De toute façon le plus important c'est ce blocage.

  • au moment du paiement, car l'URL de paiement aurait pu être envoyé à l'usager par mail, qui l'a transféré à qqun d'autre (maman qui dit à papa de payer). Et ici quel message afficher: "Erreur de paiement"? ou retourner une 404 ?

Oui, au moment du paiement, donc. C'est là qu'on va tenter de faire un GET sur « self.source_url + 'jump/trigger/paid' » : si ça répond autre chose que 404, c'est ok. Sinon, ça veut dire que la demande n'existe plus où qu'elle n'est plus dans un statut "à payer" et on va afficher un message « Cet élément n'est plus payable ».

Note : c'est un cas qui ne doit jamais arriver avec un Publik bien configuré, donc je ne me soucierai pas trop d'être clair/poli dans le message d'erreur. L'usager se plaindra, mais c'est normal, y'a bogue de configuration par un admin fonctionnel (et on ne peut pas résoudre ce bogue, il peut venir de plein de situations imprévues).

#8

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

Serghei Mihai a écrit :

On a 2 moments ou on peut faire ça:

  • on n'affiche pas l'item à payer dans le panier si un GET (signé) vers source_url retourne autre chose que du HTTP 200

C'est trop coûteux pour un truc rare, mieux vaut le faire quand on tente de payer que de ralentir le chargement de toutes les cellules paniers.

#9

Mis à jour par Serghei Mihai il y a plus de 2 ans

Benjamin Dauvergne a écrit :

C'est trop coûteux pour un truc rare, mieux vaut le faire quand on tente de payer que de ralentir le chargement de toutes les cellules paniers.

Yep, t'as raison. Surtout qu'on apprend que le lien de paiement peut être mis dans l'historique de la demande et donc l'usager peut payer sans passer par le panier.

#10

Mis à jour par Thomas Noël il y a plus de 2 ans

Voilà, rien de très compliqué.

Il y a pas mal de tests lingo modifiés, car à chaque lancement d'un paiement avec des items liés à des demandes (source_url) il y a maintenant une vérification de l'existence de chaque trigger de paiement.

(à noter, pour que ça marche bien, il faudra valider aussi #58226, sinon la détection ne sera pas parfaite et laissera passer des paiements qui n'ont plus de saut à trigger paid)

#11

Mis à jour par Thomas Noël il y a plus de 2 ans

  • Assigné à mis à Thomas Noël
#12

Mis à jour par Benjamin Dauvergne il y a environ 2 ans

  • Statut changé de Solution proposée à Solution validée
#13

Mis à jour par Benjamin Dauvergne il y a environ 2 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit 6b1f7d1d4ddb33b247f43f1c21ad3309dbb72407
Author: Thomas NOËL <tnoel@entrouvert.com>
Date:   Fri Oct 29 12:37:29 2021 +0200

    lingo: refuse payment if an item cannot be trigged (#58210)
#14

Mis à jour par Frédéric Péters il y a environ 2 ans

  • Statut changé de Résolu (à déployer) à Solution déployée
#15

Mis à jour par Transition automatique il y a presque 2 ans

Automatic expiration

Formats disponibles : Atom PDF