Project

General

Profile

Development #90195

lingo: comportement de la page de statut de paiement quand il n'y a pas de transaction_id

Added by Frédéric Péters 3 months ago. Updated 20 days ago.

Status:
Solution déployée
Priority:
Normal
Target version:
-
Start date:
30 April 2024
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No
Tags:

Description

Il y a tout un cheminement pour arriver finalement dans du js qui fait :

        if (transaction_id === "") {
          display_error($('#transaction-error').data('error'));
        }

qui affiche un message d'erreur "Une erreur est survenue".

On pourrait dès le code de la vue détecté la situation et peut-être juste rediriger vers l'accueil ? (

Associated revisions

Revision c8eeafc7 (diff)
Added by Gael Pasgrimaud 20 days ago

lingo: redirect to next_url when no transaction_id is provided to PaymentStatusView (#90195)

History

#1

Updated by Robot Gitea 21 days ago

  • Status changed from Nouveau to En cours
  • Assignee set to Gael Pasgrimaud

Gael Pasgrimaud (gpasgrimaud) a ouvert une pull request sur Gitea concernant cette demande :

#2

Updated by Gael Pasgrimaud 21 days ago

C'est un peu plus compliqué que ça. Cette page sert aussi de transition en cas d'erreur. Ca se voit dans le test unitaire modifé de la PR

La proposition modifie donc le parcours utilisateur.

Avant: soumission d'un formulaire de payement > erreur à la validation, ajout d'un django message > page de status de payment qui affiche l'erreur > bouton pour retourner a next_url (qui varie celon le contexte)

Après: soumission d'un formulaire de payement > erreur à la validation, ajout d'un django message > retour a next_url avec le message d'erreur afficher

Passer par l'étape d'avoir une page qui dit uniquement "ça a pas marché", ca me semble pas si mal. Mais ça se discute.

#3

Updated by Gael Pasgrimaud 21 days ago

Et après réflexion. Je penses qu'on a pas d'autre choix que de rejeter ce ticket. Avec la proposition faite, les messages risquent de ne pas s'afficher au bon endroit.

Par exemple, si on fait un messages.error() depuis combo. J'imagine qu'il ne s'affichera pas si next_url pointe vers wcs. Et il va apparaître quand l'utilisateur reviendra sur combo. Potentiellement deux heures après sur une page qui a rien à voir.

#4

Updated by Robot Gitea 21 days ago

  • Status changed from En cours to Solution proposée
#5

Updated by Robot Gitea 21 days ago

  • Status changed from Solution proposée to En cours

Benjamin Dauvergne (bdauvergne) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

#6

Updated by Benjamin Dauvergne 21 days ago

  • Subject changed from comportement de la page de statut de paiement quand il n'y a pas de transaction_id to lingo: comportement de la page de statut de paiement quand il n'y a pas de transaction_id
#7

Updated by Benjamin Dauvergne 21 days ago

Gael Pasgrimaud a écrit :

C'est un peu plus compliqué que ça. Cette page sert aussi de transition en cas d'erreur. Ca se voit dans le test unitaire modifé de la PR

La proposition modifie donc le parcours utilisateur.

Avant: soumission d'un formulaire de payement > erreur à la validation, ajout d'un django message > page de status de payment qui affiche l'erreur > bouton pour retourner a next_url (qui varie celon le contexte)

Si il y a des erreurs à afficher, la vue est donc utile. À mon avis l'incompréhension c'est que Fred a du arriver dessus par un parcours différent avec aucun message en session (je ne sais pas comment); ce qu'il faudrait ici c'est garder l'ancien comportement et y ajouter ton nouveau comportement dans le cas où on n'a rien à afficher.

  • Si pas de transaction_id alors:
    • Si il y a des messages en session, on affiche le template comme maintenant,
    • Si il n'y a pas de message en session, on retourne juste à '/' on est de toute façon arrivé ici pas d'une bonne manière.

Pas besoin d'ajouter un message d'erreur générique au milieu.

#8

Updated by Robot Gitea 21 days ago

  • Status changed from En cours to Solution proposée

Gael Pasgrimaud (gpasgrimaud) a demandé une relecture de Benjamin Dauvergne (bdauvergne) sur une pull request sur Gitea concernant cette demande :

#9

Updated by Robot Gitea 21 days ago

  • Status changed from Solution proposée to Solution validée

Benjamin Dauvergne (bdauvergne) a approuvé une pull request sur Gitea concernant cette demande :

#10

Updated by Benjamin Dauvergne 21 days ago

  • Tags set to paiement
#11

Updated by Robot Gitea 20 days ago

  • Status changed from Solution validée to Résolu (à déployer)

Gael Pasgrimaud (gpasgrimaud) a mergé une pull request sur Gitea concernant cette demande :

#12

Updated by Transition automatique 20 days ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF