Développement #42992
Passer une description à un backend eopayment
0%
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 (?)
Files
Associated revisions
lingo: allow passing extra basket item info (#42992)
lingo: pass extra item info to eopayment backend (#42992)
History
Updated by Benjamin Dauvergne over 4 years ago
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).
Updated by Valentin Deniaud over 4 years ago
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.
Updated by Benjamin Dauvergne over 4 years ago
Valentin Deniaud a écrit :
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: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 ?
- 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).
Updated by Valentin Deniaud over 4 years ago
- File 0001-lingo-allow-passing-extra-basket-item-info-42992.patch 0001-lingo-allow-passing-extra-basket-item-info-42992.patch added
- File 0002-lingo-pass-extra-item-info-to-eopayment-backend-4299.patch 0002-lingo-pass-extra-item-info-to-eopayment-backend-4299.patch added
- Status changed from Nouveau to Solution proposée
- Patch proposed changed from No to Yes
Updated by Benjamin Dauvergne over 4 years ago
- Status changed from Solution proposée to 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.
Updated by Valentin Deniaud over 4 years ago
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 ?
Updated by Benjamin Dauvergne over 4 years ago
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.
Updated by Valentin Deniaud over 4 years ago
- File 0003-lingo-pass-extra-item-info-to-eopayment-backend-4299.patch 0003-lingo-pass-extra-item-info-to-eopayment-backend-4299.patch added
- File 0001-lingo-allow-passing-extra-basket-item-info-42992.patch 0001-lingo-allow-passing-extra-basket-item-info-42992.patch added
- File 0002-lingo-remove-user-retrieval-from-email-in-basket-api.patch 0002-lingo-remove-user-retrieval-from-email-in-basket-api.patch added
- Status changed from En cours to Solution proposée
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.
Updated by Benjamin Dauvergne over 4 years ago
- Status changed from Solution proposée to 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.
Updated by Valentin Deniaud over 4 years ago
- Status changed from Solution validée to 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)Updated by Frédéric Péters over 4 years ago
- Status changed from Résolu (à déployer) to Solution déployée
lingo: remove user retrieval from email in basket api (#42992)