Development #27045
Paiement différé à une date arbitraire
0%
Description
La partie combo de #26914.
Pouvoir spécifier une date de remise en banque sur un BasketItem, interdire le paiement d'items aux dates de remise différentes.
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Emmanuel Cazenave il y a plus de 5 ans
- Lié à Development #26914: Paiment différé à une date arbitraire ajouté
Mis à jour par Emmanuel Cazenave il y a plus de 5 ans
- Fichier 0001-lingo-allow-arbitrary-date-for-deferred-payment-2704.patch 0001-lingo-allow-arbitrary-date-for-deferred-payment-2704.patch ajouté
- Statut changé de En cours à Solution proposée
- Patch proposed changé de Non à Oui
Première relecture bienvenue.
J'ai hésité à interdire la création d'un nouveau basket item si d'autres déjà présents non payés et avec une capture_date différente de l'item que l'on s'apprête à créer (mais rien de ce genre n'étant fait dans AddBasketItemApiView, je me suis ravisé).
Pour l'instant je me contente d'interdire le paiement d'items aux capture_date différentes.
Mis à jour par Thomas Noël il y a plus de 5 ans
Je mettrais un peu de try/except sur le item.capture_date = dateparse.parse_date(capture_date)
parce que ça va être envoyé via webservice et que ça pourrait mieux de récupérer une erreur claire dans wcs quand on va créer le paiement. Je serais aussi pour faire ce parsing dès qu'il y a un capture_date dans request_body, et pas seulemtn s'il est non vide, donc plutôt un if 'capture_date' in request_body: bla bla bla
Le message d'erreur en cas de if item.capture_date != capture_date:
est un copié collé, tu devrais avoir honte.
Mis à jour par Emmanuel Cazenave il y a plus de 5 ans
- Fichier 0001-lingo-allow-arbitrary-date-for-deferred-payment-2704.patch 0001-lingo-allow-arbitrary-date-for-deferred-payment-2704.patch ajouté
Thomas Noël a écrit :
Je mettrais un peu de try/except sur le
item.capture_date = dateparse.parse_date(capture_date)
parce que ça va être envoyé via webservice et que ça pourrait mieux de récupérer une erreur claire dans wcs quand on va créer le paiement. Je serais aussi pour faire ce parsing dès qu'il y a un capture_date dans request_body, et pas seulemtn s'il est non vide, donc plutôt unif 'capture_date' in request_body: bla bla bla
Voilà, avec les tests (et vive jsonschema ou autre).
Le message d'erreur en cas de
if item.capture_date != capture_date:
est un copié collé, tu devrais avoir honte.
Tout petit je me fais (et corrigé).
Mis à jour par Thomas Noël il y a plus de 5 ans
Je pense que l'appelant ne va pas comprendre le HttpResponseBadRequest, il faut plutôt renvoyer vers la page du paiement avec une erreur (qui sera affichée à l'usager, c'est ainsi, mais ça devrait jamais jamais arriver). ie comme quand on essaye de payer sur plusieurs régies différentes (ça non plus ça doit jamais arriver), faire plutôt :
messages.error(request, _(u'Bad format for capture date, it should be yyyy-mm-dd.')) return HttpResponseRedirect(next_url)
Par ailleurs je vois qu'on s'est pas compris pour le invalid_grouping_msg, je pensais à un message plus explicite (qui nous aidera à déboguer). On garde "Invalid grouping for basket items" pour une tentative de paiement sur x régies, mais on invente un autre pour des capture_date différentes, genre "Invalid grouping for basket items (not same capture_date)" bon tu parles anglais pas moi.
Sinon le finally n'est pas obligatoire à mon avis, mais ça fait pro.
Mis à jour par Emmanuel Cazenave il y a plus de 5 ans
- Fichier 0001-lingo-allow-arbitrary-date-for-deferred-payment-2704.patch 0001-lingo-allow-arbitrary-date-for-deferred-payment-2704.patch ajouté
Thomas Noël a écrit :
Je pense que l'appelant ne va pas comprendre le HttpResponseBadRequest ...
On est dans une vue d'API ici (peut-être que tu as été enduit d'erreur parce qu'il y avait un gettext inapproprié sur le message de l'exception, j'ai supprimé ça).
Par ailleurs je vois qu'on s'est pas compris pour le invalid_grouping_msg ..
Effectivement, voilà.
Sinon le finally n'est pas obligatoire à mon avis, mais ça fait pro.
Deuxième effectivement, et comme je préfère le minimalisme, supprimé.
Mis à jour par Thomas Noël il y a plus de 5 ans
- Statut changé de Solution proposée à Solution validée
Emmanuel Cazenave a écrit :
Thomas Noël a écrit :
Je pense que l'appelant ne va pas comprendre le HttpResponseBadRequest ...
On est dans une vue d'API ici (peut-être que tu as été enduit d'erreur parce qu'il y avait un gettext inapproprié sur le message de l'exception, j'ai supprimé ça).
Arf, désolé, exact.
Et donc, ok, hop.
(à pousser vendredi, hein)
Mis à jour par Emmanuel Cazenave il y a plus de 5 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit d40cb57e271f571cbde2808d459fe633e80c6b15 Author: Emmanuel Cazenave <ecazenave@entrouvert.com> Date: Fri Oct 5 18:36:45 2018 +0200 lingo: allow arbitrary date for deferred payment (#27045)
Mis à jour par Emmanuel Cazenave il y a plus de 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
lingo: allow arbitrary date for deferred payment (#27045)