Projet

Général

Profil

Development #27045

Paiement différé à une date arbitraire

Ajouté par Emmanuel Cazenave il y a plus de 5 ans. Mis à jour il y a plus de 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
05 octobre 2018
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

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

Lié à Publik - Development #26914: Paiment différé à une date arbitraireFermé02 octobre 2018

Actions

Révisions associées

Révision d40cb57e (diff)
Ajouté par Emmanuel Cazenave il y a plus de 5 ans

lingo: allow arbitrary date for deferred payment (#27045)

Historique

#1

Mis à jour par Emmanuel Cazenave il y a plus de 5 ans

#2

Mis à jour par Emmanuel Cazenave il y a plus de 5 ans

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.

#3

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.

#4

Mis à jour par Emmanuel Cazenave il y a plus de 5 ans

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 un if '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é).

#5

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.

#6

Mis à jour par Emmanuel Cazenave il y a plus de 5 ans

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é.

#7

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)

#8

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)
#9

Mis à jour par Emmanuel Cazenave il y a plus de 5 ans

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

Formats disponibles : Atom PDF