Project

General

Profile

Bug #1266

Améliorations sur paiment

Added by Thomas Noël over 12 years ago. Updated almost 11 years ago.

Status:
Fermé
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
17 February 2012
Due date:
% Done:

100%

Estimated time:
Patch proposed:
Planning:

Description

Un gros patch qui revoie le code de paiment.

Validation des paiments :
* ajout de regie.validate_on_browser_redirect : permet à une régie d'accepter la confirmation du --paiement sur le redirect final (utile si le callback n'a pas marché) [patch de benjamin]
* on enregistre invoice.paid=True même si le formdata associé n'est plus en état d'attente du paiement (en théorie le workflow devrait faire que ça n'arrive jamais, mais je préfère que le paiement soit marqué comme effectué de toutes façons)

Programmation des workflows : une seule action de workflow
* suppression de l'action "en attente de validation"
* c'est dans l'action de création d'un paiment qu'on indique le statut cible après validation

Gestion du user_hash "bête et méchante": on copie le user_id et le user_hash du formulaire dans l'invoice

Associated revisions

Revision f0a875e0 (diff)
Added by Thomas Noël over 12 years ago

workflow after payment: get next_status from different sources

fix #1266

History

#1

Updated by Thomas Noël over 12 years ago

[17:02:17] fred: tiens, désolé de n'y penser que maintenant, le "attente de validation", il pouvait aussi servir à ne pas bloquer sur le statut contenant la création de l'invoice, il suffisait derrière dans les statuts de workflow potentiels d'avoir le "attente de validation".
[17:02:24] fred: (enfin, à lire le patch, je pense à ça)
[17:02:53] Thomas: (on vient d'avoir un sale crash de auquo à cause des quota vz, on est là dessus pour que ça revienne pas)
[17:05:09] Thomas: statut "attente de validation" : avec son retrait, y'a pas de pb de blocage, le futur statut je le stocke dans l'invoice ... donc en attendant le paiment le formdata peut faire ce qu'il veut (ou bien j'ai pas compris le sens de ta remarque ?)
[17:06:26] fred: comme il pouvait être à plusieurs endroits, il pouvait ensuite emmener vers différents statuts, alors que maintenant on est contraint à un seul, qui peut se retrouver en dehors du "flow".
[17:09:01] Thomas: mmh... avant le patch, la création d'une facture envoyait vers un statut qiu devait contenir l'attente de validation... et donc pas vraiment possible d'en avoir plusieurs... non ?
[17:09:21] fred: on pouvait imaginer avoir plusieurs statuts avec l'attente de validation.
[17:10:07] Thomas: oui, je comprends, mais puisqu'on envoyait le formdata dans un seul statut lors de la création du paiement...
[17:10:44] fred: ce statut pouvait contenir différents choix, etc.
[17:11:08] Thomas: ok mais si le gars paye entre temps, ça explosait...
[17:11:11] fred: et les statuts en aval auraient aussi eu "waiting for validation".
[17:12:13] Thomas: ah
[17:12:17] Thomas: je commence à comprendre :)
[17:12:29] fred: je sais pas si c'est important :)
[17:12:56] fred: mais si on considère que non, faudrait empêcher qu'un statut créant un paiement puisse être quitté par autre chose que la réception du paiement.
[17:13:32] Thomas: oui, et sinon il faut ajouter une action de workflow "détruire la demande de paiement" 
[17:14:08] fred: yep, c'était https://dev.entrouvert.org/issues/611 :)
[17:14:31] Thomas: oui, de toute façon il faudra que je l'ajoute
[17:14:55] fred: bref, je te laisse choisir la direction.
[17:14:55] Thomas: finalement je me dis, je pourrais reprendre le "waiting for paiment" 
[17:15:45] Thomas: si le formulaire est dans un état qui a cette action, je bascule, et sinon je vais vers l'état indiqué dans l'invoice
[17:15:57] Thomas: mais ça devient assez tordu à expliquer, c'est ça qui m'inquiète un peu
[17:16:12] Thomas: quoique comme le dit victor : a priori les paiments, ça sera toujours à nous de les configurer ;)
[17:16:13] fred: oui, le mix des deux, c'est trop complexe.
[17:16:48] Thomas: en fait ce qui m'inquiète
[17:17:18] Thomas: c'est que si le formdata se retrouve dans un état qui n'a pas de "waiting" 
[17:17:21] Thomas: et que la personne paye...
[17:17:24] Thomas: ben... on fait quoi ?
[17:18:08] Thomas: c'est un cas anormal, ceci dit, si le workflow est correctement géré
[17:18:33] Thomas: mais j'ai quand même un peu peur du "déblocage" à cause de ça
[17:19:33] fred: alors allons pour la solution mixant les deux, s'il y a un waiting, on le suit, sinon on fallback sur ce qui aura été défini dans le PaymentWorkflowStatusItem
[17:20:12] Thomas: une autre idée serait d'indiquer les paiment créés / validés dans l'évolution
[17:20:24] Thomas: charge à l'agent de bien vérifier que le mec a payé
[17:20:40] Thomas: ça serait de toute façon un truc à faire, d'ajouter cette info, même en cas de "mix" 
[17:20:47] fred: oui, en plus.
[17:20:52] Thomas: bon
[17:21:07] fred: désolé d'avoir pensé à ça en lisant le patch
[17:21:24] Thomas: non non pas de soucis c'est vraiment pas méchant
[17:21:34] Thomas: je sais faire des copier coller ;)
[17:21:52] Thomas: et ça va assouplir les possibilités
[17:21:59] Thomas: je plain juste le gars qui va ecrire la doc ;)
[17:22:18] fred: faudra l'embaucher un jour…
#2

Updated by Thomas Noël over 12 years ago

  • % Done changed from 0 to 90

Appliqué par commit r591.

#3

Updated by Thomas Noël over 12 years ago

  • Description updated (diff)
  • Target version set to Au-quotidien 2012.2
#4

Updated by Thomas Noël over 12 years ago

  • File deleted (auquo-payment.diff)
#5

Updated by Thomas Noël over 12 years ago

  • Status changed from Solution déployée to Résolu (à déployer)
#6

Updated by Thomas Noël over 11 years ago

  • Status changed from Résolu (à déployer) to Fermé
#7

Updated by Frédéric Péters almost 11 years ago

  • % Done changed from 90 to 100

Also available in: Atom PDF