Produits Entr'ouvert » EOPayment

Tu changes la signature de request et donc je suppose les appels dans lingo, mais c'est une signature partagée, ça va faire quoi sur un autre déploiement que Fondettes avec un autre backend ?

Idéalement request() peut prendre des choses aussi fines que ça mais dans les autres backend il faudrait mapper ça sur soit des champs aussi fins soit des champs moins fins (si on a que "name" alors on fait name <- first_name + ' ' + last_name). Le patch sera accepté si il corrige ça dans tous les backends.

Pour sips2 il y a un customerId où tu peux essayer de mettre unicode(name or ' '.join(filter(None, [first_name, last_name]))).

Pour pas t'embêter je ferai la conversion first_name / last_name -> name dans l'objet d'entrée de l'API: eopayment.Request, idem pour ton log de debug.

Benjamin Dauvergne a écrit :

Pour pas t'embêter je ferai la conversion first_name / last_name -> name dans l'objet d'entrée de l'API: eopayment.Request, idem pour ton log de debug.

Tu veux dire dans Payment.request ?

Oui celui qui est dans eopayment/__init__.py.

On import pas logging depuis common, on importe logging tout court.

Ça non:

        logger.debug(' '.join(['%s: %s' % (k, v) for k, v in kwargs.iteritems()]))

Je préfère encore ça u'%r' % kwargs c'est moins long, c'est moins dangereux, c'est du debug on s'en fout du formatage.

Et donc là mea-culpa, pas la peine d'ajouter first_name et last_name aux backends qui ne peuvent pas s'en servir, et donc tu peux faire un git checkout HEAD~ sur dummy, ogone, paybox, sips et spplus. Après je pense que c'est bon.

T'as perdu l'implémentation sips2.

Je ne sais pas ce que tu fais mais maintenant tu as perdu le code qui était dans Payment.request pour concaténer first_name et last_name en entrée (ce qui permettra de simplifier le code dans sips2).

Je l'ai zappé exprès, car la prise en compte de first_name et last_name se fait uniquement dans les backends qui s'y attendent. Comme dans Payzen l'attribut name est obsolète et disparaitra un jour et il restera seul le module sips2 qui s'en servira. J'ai donc pensé que la concatenation des first_name et last_name se ferait au niveau du backend et non du request général.

Ack.

Je ne suis pas à l'aise avec cette modification côté sips2; customerId n'est pas repris dans ma copie de la spec, uniquement dans le document annexe "Data Dictionary" et c'est repris comme étant "customer identifer" et devant être au format ANS19 (restrictedString (va savoir)). Le prénom et le nom de la personne facturée, ce serait dans billingContact.firstname et billingContact.lastname.

Si ça a été testé pour de vrai et que c'est accepté par Atos, très bien, mais je n'ai pas envie de découvrir un bug après que Liège ait mis à jour.

Je me suis fié à la copie qui est dans le wiki, si tu en as une mieux/plus récente, je veux bien que tu l'attaches à la page d'accueil du wiki.

Pour cette documentation j'ai la même version, et dedans il y a peu d'info sur customerId (ce ticket décide d'essayer d'y taper nom/prénom) et il est mentionné billingContact.firstname et .lastname (et comme on utilise déjà billingContact.email, ça me semble peu risqué). (j'ai ajouté l'annexe "Data dictionary" au wiki).

Mettons ça dans billingContact.firstname/lastname, pas de soucis.

Ack.

commit 8320be27ddd8fed8f19f9925b1bef36924ce3218
Author: Serghei Mihai <smihai@entrouvert.com>
Date:   Mon Sep 12 16:21:31 2016 +0200

    sips2: pass user's first and last names in allowed attributes (#12447)