[ADD] payment_acquirer: in the rendering, now supported in the context :
- tx_url: the form action URL, that can be set by the context, otherwise fall back on the acquirer default tx URL
- submit_class and submit_txt: submit is now a button with an image, unless asked not to; used in the ecommerce to display a Pay Now button instead of the acquirer logo
- updated all acquirers accordingly.
[IMP] payment_acquirer: cleaned and improved form view, for acquirer and tx models.
[IMP] payment_acquirer: amount and fees are now (16,2) float fields. Updated code to handle this kind of floats. Probably those values should come from some config parameters, but it is still not the case.
[CLEAN] various acquirers: removed unnecessary fields, among other the fields holding URLs. URLs of an acquirer should be accessible through a method, but storing them in a field is wasted space. Updated all acquirers and code accordingly.
[FIX] various acquirers: fixed ckeckout and getting data back processes. Some fixed in the controllers, some fixes in the data management due to prior refactoring and improvements in website and acquirer model.
[IMP] website_sale: updated the choice of the acquirer. They are all displayed with a small image as radio input; a Pay Now button is present to activate the payment process. Actually each acquirer generated a Pay Now button, but only the one of the chosen acquirer is displayed. This rendering uses the new options added in the button rendering process described hereabove.
[REM] website_payment: removed most of the code that was present for testing purposes. Only some JS is kept, for future credit-card form rendering.
bzr revid: tde@openerp.com-20131204175715-gdbl0tp5vbnc6pxm
Now all acquirer are displayed using a small icon; a Pay Now button is located on the right that
is the next step for the payment.
All acquirers are rendered with a Pay Now button, but only the currently chosen one is
displayed. This allows to display several acquirers without having to do javascript-based
hacks to tune the form, its action or content.
bzr revid: tde@openerp.com-20131204130628-eeqpfhoqaavhv6nk
- confirmation is now a page displaying a sale order, which polls on the
related transaction to have its status
- when receiving an incoming notification thorugh the acquirer controller
the sale order is updated, then the confirmation page is displayed
- this allows to have a confirmation page that is independant from the
rest of the checkout process
- cleaned confirmation page, removed order details
bzr revid: tde@openerp.com-20131121120902-fm8b7u94gmepohgi
- added a controller that validates the payment: confirm the quotation (if paid)
and send it by email
- some fixes in payment routes
- some cleaning in payment template, removed unnecessary code, added a class on a
div to ease the submit button management
bzr revid: tde@openerp.com-20131120140321-mderltwy8xp2vfn4
- now going to shop/confirmation when coming back from the acquirer
- added poll on the confirmation page to wait for data from acquirer
- misc cleaning of checkout process, order and transaction management
- added cancel state on payment.transaction, when canceled by the
customer
bzr revid: tde@openerp.com-20131119160129-fkwkhjvk1bh0uarf
The action of the rendered button is catched, re-routed to a custom controller in sale that
creates the payment.transaction, or fetch an already-existing one.
Once the transaction is found or created, the user is redirected to the acquirer
transaction url.
Next step: display the transaction status in the payment page.
bzr revid: tde@openerp.com-20131115133414-jiob0gkpv106db27
Christophe Matthieu
Fabien Pinckaers
Fabien Meghazi
Thibault Delavallée
Fabien Pinckaers
ddm