[RENAME] payment_acquirer_* -> payment_ *
[CLEAN] payment_paypal duplicate of portal.payment.acquirer
- [REM] portal.payment.acquirer model, now replaced by payment.acquirer
- paypal banner generation on sale orders and invoices is done using the new payment.acquirer model. It basically works like the old portal.payment.acquirer, using a render_payment_block method.
[CLEAN] payment_paypal and paypal_account field of res.company
- in account: paypal_account is a char field (nothing changes)
- when installing payment_paypal: the char field is replaced by a function field that looks in the payment.acquirer table for paypal instances and get the first one back
- when installing payment_paypal, the company.paypal_account value is used to replace the default paypal data
- this function field and 'migration mechanism' are company aware
[IMP] payment: added pre_msg, post_msg, that are messages to be displayed before payment (like redirection warning for Paypal) and after payment (like account and communication details for transfer). Added a default message for transfer taking the visible company bank accounts.
[IMP] payment: added manual / automatic distinction. eCommerce use this information to decide whether to poll the tx status or display an information message.
[FIX] payment_*: fixed return controlers, using werkzeug.redirect instead of request.redirect that does not work anymore
[IMP] configuration
- added checkboxes to install paypal, ogone and adyen directly from the invoicing configuration
bzr revid: tde@openerp.com-20140124152541-y6e6kset056jbpkv
payment. Added post_msg, message displayed after payment.
[IMP] payment_transfer: added a default value (generated at create) for
post_msg, that contains bank accounts details. bank accounts linked to the
current company and used in report footer are shown.
[FIX] payment_*: make the buttons noupdate.
[IMP] payment: portal_published -> website_published + propagation
[IMP] payment: added process selection field that will be used for some
control in the website, telling w hether we want to refresh a payment
validation page or not.
bzr revid: tde@openerp.com-20140124134652-cc0nz08znnlmftw4
product_template inheritance: added email_template_id field, link to an optional email.template
invoice inheritance: when validating the invoice, send an email for each product that has a linked email.template.
email_template inheritance: defined a new simplified form view with only attachment_ids and body, to ease the quick edition of email templates. This simplified form view is used for the email_template_id field on the product.template form view.
email_template: when having default_model in default_get, use it to prefetch model_id. Indeed model is a related file, we have to redirect its default to the right model_id field.
bzr revid: tde@openerp.com-20140124120652-vxp0jwf14sl1frme
This had as side-effect to not allow splitting BOMs
(a manufacturing order for 1 unit of a BOM producing 10 units consumed the lines like it was 10 units, not 1)
This fix was to avoid having a fraction of a unit (for instance, 0.5 unit).
But, finally, it is preferable to allow splitting units:
1. Most users do not use several uoms, and in this case, the unit is the default uom (hidden).
2. At the moment, it is allowed to ask a manufacturing order splitting up the unit uom
(It is allowed to ask the production of 0.5 USB Adapter, for instance)
Thus, we should allow the splitting up of the unit uom in the lines too.
bzr revid: dle@openerp.com-20140124120102-we2yxio553ws2yz4
Christophe Simonis