payment was added as dependance of portal_sale, which used to be auto installed when portal and sale were installed. With this new dependance, it wasnt the case anymore
With auto install of the payment module with the installation of account, this module is installed on the installation of sale (depends on account), and, therefore, on the installation of portal, portal_sale is now installed correctly
bzr revid: dle@openerp.com-20140410084846-78kxwc63nmv0rg9k
from the name. This allows to distinguish name and provider. Provider is a more
technical field, used to call some specific methods (<provider>_method_name). The
name field is used for display on the website.
Code and views udpated accordingly.
bzr revid: tde@openerp.com-20140319144608-0i4rv520l0bh53f0
[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
- added a call to _migrate_paypal_account in the payment_paypal data that
does the migration from company.paypal_account (char field) to a payment.acquirer
and company.paypal_account becoming a function field, with a getter / setter.
This function field is company aware.
- added an update of the res_config view of invoicing to link to the list
of acquirers
- added possibilty to install acquirers from invoicing (paypal / ogone / adyen
are installable through config)
bzr revid: tde@openerp.com-20140123150135-07b4pkbjade6vimq
now based on the new implementation of payment.
[REM] portal: removed acquirer model, views and implementation
[REF] portal_sale: now using payment rendering methods
[IMP] payment: added render_payment_block, taken from old
acquirer, that renders all portal_published acquirers.
bzr revid: tde@openerp.com-20140122190022-lef4b3o1tpcua3vx
Thibault Delavallée
Christophe Simonis
Denis Ledoux
Kersten Jeremy
Antony Lesuisse
Christophe Matthieu