Projet

Général

Profil

Development #42992

Passer une description à un backend eopayment

Ajouté par Valentin Deniaud il y a presque 4 ans. Mis à jour il y a presque 4 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
18 mai 2020
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

Actuellement si un backend gère une description, elle est définie statiquement au moment de son paramétrage, donc commune à tous les paiements. Lingo pourrait à la place générer une description dynamique à chaque paiement, qui reprenne en plus du nom du site, le nom de l'usager et le contenu du panier (?)


Fichiers

Révisions associées

Révision fca2a33b (diff)
Ajouté par Valentin Deniaud il y a presque 4 ans

lingo: remove user retrieval from email in basket api (#42992)

Révision 1bdc2368 (diff)
Ajouté par Valentin Deniaud il y a presque 4 ans

lingo: allow passing extra basket item info (#42992)

Révision 1c0c3658 (diff)
Ajouté par Valentin Deniaud il y a presque 4 ans

lingo: pass extra item info to eopayment backend (#42992)

Historique

#1

Mis à jour par Benjamin Dauvergne il y a presque 4 ans

Certains backends sont capable de gérer ça finement ou pas (séparer le numéro de la facture, du nom de la collectivité, etc...) ensuite grouper ça peut devenir indigeste sur les backends qui ne supporte qu'une information (ex.: description) par exemple si on met tout le contenu du panier.

Donc le mieux ce serait d'accepter des informations séparés (email, élément du panier avec chacun une description, un numéro de facture ou de demande, etc..) et dans chaque backend on décide si on peut envoyer ces informations tels quels, ou regrouper, ou un sous-ensemble (regroupé ou pas).

Mais ça demande aussi de travailler coté lingo pour étendre les informations qu'on peut passer au moment de l'ajout d'un élément au panier (dans le cas connecté et non connecté, par exemple il serait utile de pouvoir passer l'email de l'utilisateur dans le cas connecté, voir #42456).

#2

Mis à jour par Valentin Deniaud il y a presque 4 ans

Benjamin Dauvergne a écrit :

nom de la collectivité

C'est une bonne idée de passer ça je pense, mais j'obtiens ça comment ? global_title dans les TEMPLATES_VAR ?

Mais ça demande aussi de travailler coté lingo pour étendre les informations qu'on peut passer au moment de l'ajout d'un élément au panier (dans le cas connecté et non connecté, par exemple il serait utile de pouvoir passer l'email de l'utilisateur dans le cas connecté, voir #42456).

Mauvais numéro de ticket ?

un numéro de facture ou de demande

Qui eux sont actuellement passés dans le display_name au moment de l'ajout au panier, donc il faut effectivement permettre de faire autrement.

#3

Mis à jour par Benjamin Dauvergne il y a presque 4 ans

Valentin Deniaud a écrit :

Benjamin Dauvergne a écrit :

nom de la collectivité

C'est une bonne idée de passer ça je pense, mais j'obtiens ça comment ? global_title dans les TEMPLATES_VAR ?

Dans un premier temps je pensais simplement tout passer dans le panier et la source de facture, il faut juste dégager quelques conventions, les documenter et s'y tenir:
  • reference_id : pour le numéro de commande ou de facture,
  • merchant_name : pour la collectivité,
  • email : pour l'email de l'acheteur.

Etc... l'idée c'est juste qu'on trouve les 3/4 infos récurrentes possibles (ou obligatoire pour le cas de PayFiP/TIPI plus bas) et qu'on puisse les propager du formulaire/de la source de facture jusqu'au backend.

Maintenant avoir des métadonnées conventionnelles de ce genre au niveau plate-forme, pourquoi pas. Pour le nom de la collectivité on a déjà par exemple la variable global_title qui est utilisée dans les thèmes.

Après ça dépend aussi de la longueur qu'on peut mettre dans description, si tu peux y mettre {{ global_title }} - ref: {{ reference_id }} - {{ email }} c'est bien, mais ce n'est peut-être pas toujours possible :/ Il faut vraiment croiser tous les backends pour voir ce qui est envisageable.

Mais ça demande aussi de travailler coté lingo pour étendre les informations qu'on peut passer au moment de l'ajout d'un élément au panier (dans le cas connecté et non connecté, par exemple il serait utile de pouvoir passer l'email de l'utilisateur dans le cas connecté, voir #42456).

Mauvais numéro de ticket ?

Ouaip, c'est #42525.

un numéro de facture ou de demande

Qui eux sont actuellement passés dans le display_name au moment de l'ajout au panier, donc il faut effectivement permettre de faire autrement.

On va pas changer ça, le display_name est libre, c'est ce que les gens voient et c'est suffisant, mais qu'on ait des détails structurés à coté possibles serait un plus (même si c'est redondant avec display_name, c'est pas grave, ça n'a pas le même usage).

#4

Mis à jour par Valentin Deniaud il y a presque 4 ans

  • Assigné à mis à Valentin Deniaud
#6

Mis à jour par Benjamin Dauvergne il y a presque 4 ans

  • Statut changé de Solution proposée à En cours

0001 :

                user = User.objects.get(email=request.GET.get('email'))
            else:
                user = None
                item.email = request_body.get('email_address') or ''

Cette différence email_address/email est triste mais je comprend le problème (pour dire que je vois que tu fais du mieux que tu peux compte tenu de l'existant), enfin c'est triste quand même. Est-ce qu'on ne tenterait pas d'ignorer le cas ou on ne trouve pas l'utilisateur ? Je pousserai même à déprécier l'usage de l'email pour trouver l'utilisateur sur le portail, c'est pour faire comme w.c.s. mais ça n'a jamais servi, la vrai référence c'est bien le NameID et la seule qui sera toujours disponible, une simple recherche sur la prod montre que ce n'est pas utilisé une seule fois :

bdauvergne@wcs.node1.prod:/tmp$ sudo -u wcs wcs-manage runscript --all-tenants find-url.py 2>&1 | grep add-basket | grep email
bdauvergne@wcs.node1.prod:/tmp$ cat find-url.py 
from quixote import get_publisher
from wcs.workflows import Workflow

host = get_publisher().app_dir.split('/')[-1]

for wf in Workflow.select():
    for status in wf.possible_status or []:
        for item in status.items or []:
            if getattr(item, 'url', None):
                print(host, item.url)


Le 0002 c'est tout bon pour moi, faudra ajouter le support pour merchant_name et items_info dans la foulée.

#7

Mis à jour par Valentin Deniaud il y a presque 4 ans

Benjamin Dauvergne a écrit :

Est-ce qu'on ne tenterait pas d'ignorer le cas ou on ne trouve pas l'utilisateur ?

Ça me paraît être un vecteur d'attaque, un utilisateur anonyme pourrait potentiellement spammer le panier d'autres personnes en connaissant leur email.

Je pousserai même à déprécier l'usage de l'email pour trouver l'utilisateur sur le portail

Oui mais comment on déprécie quelque chose que personne n'utilise et qui n'est pas dans la doc ? On le supprime et problème réglé, non ?

#8

Mis à jour par Benjamin Dauvergne il y a presque 4 ans

Valentin Deniaud a écrit :

Benjamin Dauvergne a écrit :

Est-ce qu'on ne tenterait pas d'ignorer le cas ou on ne trouve pas l'utilisateur ?

Ça me paraît être un vecteur d'attaque, un utilisateur anonyme pourrait potentiellement spammer le panier d'autres personnes en connaissant leur email.

Il faut quand même une signature pour accéder à cette API, c'est pas open bar (ou alors on a un problème plus grand).

Je pousserai même à déprécier l'usage de l'email pour trouver l'utilisateur sur le portail

Oui mais comment on déprécie quelque chose que personne n'utilise et qui n'est pas dans la doc ? On le supprime et problème réglé, non ?

Oui j'euphémise j'attendais que quelqu'un intervienne pour dire « oui ça ne sert à rien » et pouvoir dire virons le alors; alors virons le.

#9

Mis à jour par Valentin Deniaud il y a presque 4 ans

Benjamin Dauvergne a écrit :

Il faut quand même une signature pour accéder à cette API, c'est pas open bar (ou alors on a un problème plus grand).

(je parlais bien du cas où c'est wcs qui appelle : paiement sans panier, formulaire, prendre le champ email du formulaire et le passer dans add-basket-item, badaboum)

Oui j'euphémise j'attendais que quelqu'un intervienne pour dire « oui ça ne sert à rien » et pouvoir dire virons le alors; alors virons le.

Et du coup à lire le code, ça sert surtout à dire « pas de dépendance stricte à mellon, ça peut marcher sans » et « c'est plus pratique dans les tests » (le cas NameId n'est même pas testé, tout est à base d'email). Je change tout ça dans un patch 0002 séparé, donc.

#10

Mis à jour par Benjamin Dauvergne il y a presque 4 ans

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

Valentin Deniaud a écrit :

Benjamin Dauvergne a écrit :

Il faut quand même une signature pour accéder à cette API, c'est pas open bar (ou alors on a un problème plus grand).

(je parlais bien du cas où c'est wcs qui appelle : paiement sans panier, formulaire, prendre le champ email du formulaire et le passer dans add-basket-item, badaboum)

Ok, effectivement dans ce cas c'est mal.

Oui j'euphémise j'attendais que quelqu'un intervienne pour dire « oui ça ne sert à rien » et pouvoir dire virons le alors; alors virons le.

Et du coup à lire le code, ça sert surtout à dire « pas de dépendance stricte à mellon, ça peut marcher sans » et « c'est plus pratique dans les tests » (le cas NameId n'est même pas testé, tout est à base d'email). Je change tout ça dans un patch 0002 séparé, donc.

Ok.


Le changement email_address -> email devrait retourner dans le patch 0001 sinon c'est tout bon.

#11

Mis à jour par Valentin Deniaud il y a presque 4 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit 58c2e1f8fc79bb70388b5a446a56eb9d5ad3d9c4
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Thu Jun 4 14:29:37 2020 +0200

    lingo: pass extra item info to eopayment backend (#42992)

commit 3cd8c426429b059c615cd1a80711d46700b6c9ff
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Thu Jun 4 14:28:47 2020 +0200

    lingo: allow passing extra basket item info (#42992)

commit a032a45cc361069390cfcf7413cd50888f345d9e
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Wed Jun 10 10:47:12 2020 +0200

    lingo: remove user retrieval from email in basket api (#42992)
#12

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

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

Formats disponibles : Atom PDF