[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
- fixed controller: when using urlopen and read, the response is already a text (bug coming
from the removal of requests lib)
- cleaned and fixed paypal data validation, now working
- remove paypal_username field, not used; added paypal_seller_id that is the unique ID of the
seller, to check that paypal data is correct
- various code cleaning
bzr revid: tde@openerp.com-20131204160738-q9paazleyg5v5hjo
Force readonly="0" on field image in preferences view, otherwise the readonly can be set by access rights.
Preferences are written with the UID 1, if the fields are in the WRITEABLE FIELDS list of the object res_users.
This is why any users can edit their preferences even if they do not have the rights to write on res.users.
Forcing readonly="0" to make fields editable in the form.
bzr revid: dle@openerp.com-20131204145923-f7jwoah722q188d7
Because defaults get function of partner_id of wizard read the partner_id of the opp and return the first item of the tuple, but if there isnt a partner on the opp, the read return a false for this field, not a tuple.
No return the first item of the tuple if the partner_id is set, else False
bzr revid: dle@openerp.com-20131204133633-t7wfbnipv3jtss82
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
- added acquirer_reference standard field on the transaction, valid for most of acquirers
- fixed computation of partner_data before rendering the button, was broken when giving a
partner_id
- added support of tx_url to specify the form URL for the rendered button
- added support of submit_txt and submit_class to customize the submit button of the
rendered form
bzr revid: tde@openerp.com-20131204125227-3g017gue72ujjyqz
In im_session model, field channel_id was a many2one to im_user, or, obviously, this should be a many2one to im_livechat.channel
Well, obviously, this is a copy/paste error (or distraction, your choice!). This fix should normally not be pushed on a stable branch (like the current one, saas-2), but considering the severity of the problem, and the few changes in database (alter foreign key only), this is acceptable. Why such a big mistake has not been seen earlier ? Do you even test or read back what you write ?
bzr revid: dle@openerp.com-20131204122727-q0ch5j2v8rrli41e
According to user tests, users have a hard time finding out how to
edit links. Thus, add same system as image edition (a small button
appearing when hovering the element).
Extract and unify these two to avoid redundancies between handlings as
they are broadly similar (only details such as label, positioning and
size of button relative to the element being hovered really change,
the lifecycle itself is the same).
The main setup still isn't very clean, there might be a better way to
do it.
bzr revid: xmo@openerp.com-20131204105212-u0a49nbvwilgtfst
Thibault Delavallée