The installation of a new acquirer was a bit complicated : from settings,
check the acquirer, then apply (install the module) then list view of
acquirer and finally edit it in form view.
This needed to be simplified. The payment acquirers are pre-filled
in payment. From the kanban view an `Install` button installs and
redirects to the form field.
This commit adds a new model, Payment Method, which stores
a reference to the payment acquirer's database and a reference to
a partner. Each payment module must have its own implementation.
The implementation is completely abstract but may not suit every
provider's way of implementing recurring payments.
Do not allow everybody to access account.transactions.
Restrict by default to readonly and even restrict the access with a record rule, give access to salesman.
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
- 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
Martin Geubelle