Produits Entr'ouvert » Combo

Création un endpoint de callback par PaymentBackend, sur le même principe que le endpoint de callback d'une régie (qu'on conserve également).

Qu'on conserve parce que compatibilité avec l'existant parce que des URL ont été enregistrées dans les backoffice de systèmes de paiement, c'est ça ?

Oui, autre plan ?

De manière sauvage :

-    url(r'^lingo/callback/(?P<regie_pk>\w+)/$', CallbackView.as_view()),
+    url(r'^lingo/callback/.*', CallbackView.as_view(), name='lingo-callback'),

Évidemment ça ne prendra pas cette forme mais ça devrait pour moi être une unique vue, qui ignore tout à fait l'info "regie_pk" et se base uniquement sur la transaction (retrouvée via appel aux backends.guess_whatever()).

Je remplacerais "pb" par "payment_backend", ça facilitera les lectures plus tard.

Je m'interroge sur la description obligatoire (dans la pratique, il me semble qu'on n'y met souvent presque rien, juste parce qu'il faut remplir).

Pour limiter les changements, j'aurais modifié get_eopayment_object() pour accepter régie ou backend de paiement.

Je déplacerais le retrait dans regie.compute_extra_fees(user=transaction.user) dans un commit indépendant "lingo: don't recompute fees after payment (it was for partial payments) (#.....)".

J'imaginais les backends de paiement plus bas niveau que les "régies", et que du coup ce qui serait proposé comme accès principal aux utilisateurs aie plutôt été un accès à celles-ci, c'est l'inverse qui est fait. À réfléchir un peu je serais pour garder "backends" et "régies" côte à côte, ne pas y inscrire de hiérarchie. (aussi parce que ça me semble permettre de simplifier toutes les vues).

On peut négocier ? (ça ferait pas mal de boulot à la poubelle de tout revoir).

Bof, il s'agit de 1/ ne pas toucher à toute la partie régie, garder un lien vers la liste là où il est aujourd'hui, 2/ retirer toute la partie "régie" des vues "backend de paiement" je trouve que ça simplifie pour l'usager et que ça simplifie le code. Il me semble que ça concerne uniquement 0003, donc il n'y a même pas de rebase compliqué à craindre.

Si c'est une question de temps, je peux me charger de cette reprise du 0003, pour te donner du temps sur #32969 que je trouve également important.

À l'exécution des migrations chez moi :

  File "/home/fred/src/eo/venv1.11/local/lib/python2.7/site-packages/django/db/migrations/operations/special.py", line 193, in database_forwards
    self.code(from_state.apps, schema_editor)
  File "/home/fred/src/eo/combo/combo/apps/lingo/migrations/0035_auto_20190426_1124.py", line 14, in create_backends
    service=regie.service, service_options=regie.service_options)
  File "/home/fred/src/eo/venv1.11/local/lib/python2.7/site-packages/django/db/models/base.py", line 573, in __init__
    raise TypeError("'%s' is an invalid keyword argument for this function" % list(kwargs)[0])
TypeError: 'description' is an invalid keyword argument for this function

(simplement en virer l'attribut description permet de passer)

Dans la liste des régies on a <span>({{regie.service}})</span> qui ne donne plus rien.

Je monterais payment_backend entre description et is_default.

Les liens "annuler" devraient retourner sur la page listant les régies/backends (mais je pense avoir lu ça déjà, c'est peut-être un truc fait dans un autre patch).