Odoo/addons/payment/__init__.py, branch 14.0 The current checkout of upstream Odoo [FIX] payment: payment acquirer disabled on uninstall 2020-04-06T13:26:23+00:00 Nicolas Lempereur nle@odoo.com 2020-04-06T10:51:00+00:00 844a4cb49bfc12e5c22d327aa6f1b064c64c93e8 When we uninstall a payment acquirer, its state should be `disabled` because when we succedingly reinstall it, we want the required_if_provider fields to possibly be unset (which is only possible if the state is not in `enabled` or `test`). opw-2223094 closes #49033 closes odoo/odoo#49061 X-original-commit: ddf07ef2d9741d1db546efb1364718ff9e247aaf Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com> 
When we uninstall a payment acquirer, its state should be `disabled`
because when we succedingly reinstall it, we want the
required_if_provider fields to possibly be unset (which is only possible
if the state is not in `enabled` or `test`).

opw-2223094
closes #49033

closes odoo/odoo#49061

X-original-commit: ddf07ef2d9741d1db546efb1364718ff9e247aaf
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
[FIX] payment_*: reset payment acquirers to default on uninstall 2020-04-02T21:47:21+00:00 Adrian Torres adt@odoo.com 2020-03-30T08:39:00+00:00 0cb6f111b8eb420044eb2636710570b56d753e67 The `payment` module introduces a certain amount of payment acquirers, each one corresponding to a `payment_` module. When a `payment_` module is installed, this data is updated so that payments done with the corresponding acquirer change in behaviour using the provider installed by the `payment_` module. When a `payment_` module is uninstalled, this data should be reset to default, more especifically the `view_template_id` and the `provider` fields of `payment.acquirer`. This was not possible before this commit, and more importantly it would make the uninstallation of such `payment_` module impossible as the `view_template_id` is a required m2o ondelete='set null', which will make the registry crash. Even if the former wasn't a problem, the provider field would remain set to a non-existing selection option, which would make the registry crash (eventually, when checking a record with such a selection option). With this commit, we reset these fields to their default value upon module uninstall. In 13, the issue with `view_template_id` should be fixed, as required m2o that are ondelete='set null' are no longer possible. As for the provider Selection field, a fix should arrive in master soon. opw-2225333 closes odoo/odoo#48916 X-original-commit: 4f0c1c1bfd71dd1ff6793d0a91b49984c54d1351 Signed-off-by: Raphael Collet (rco) <rco@openerp.com> Signed-off-by: Adrian Torres (adt) <adt@odoo.com> 
The `payment` module introduces a certain amount of payment acquirers,
each one corresponding to a `payment_` module.

When a `payment_` module is installed, this data is updated so that
payments done with the corresponding acquirer change in behaviour using
the provider installed by the `payment_` module.

When a `payment_` module is uninstalled, this data should be reset to
default, more especifically the `view_template_id` and the `provider`
fields of `payment.acquirer`.

This was not possible before this commit, and more importantly it would
make the uninstallation of such `payment_` module impossible as the
`view_template_id` is a required m2o ondelete='set null', which will
make the registry crash. Even if the former wasn't a problem, the
provider field would remain set to a non-existing selection option,
which would make the registry crash (eventually, when checking a record
with such a selection option).

With this commit, we reset these fields to their default value upon
module uninstall.

In 13, the issue with `view_template_id` should be fixed, as required
m2o that are ondelete='set null' are no longer possible. As for the
provider Selection field, a fix should arrive in master soon.

opw-2225333

closes odoo/odoo#48916

X-original-commit: 4f0c1c1bfd71dd1ff6793d0a91b49984c54d1351
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
[ADD] account: onboarding panel for invoicing 2018-07-20T09:59:12+00:00 eco-odoo eco@odoo.com 2018-05-28T10:35:54+00:00 d1ec3306b8a75f8b961192ef5cf39b6f454f3792 Add an onboarding panel for invoicing, it appears above the invoice list. After going through the steps the system should be all set to send real invoices. In the payment module, add a payment acquirer step and add it to the invoice onboarding panel. task: 60668 
Add an onboarding panel for invoicing, it appears above the invoice
list.
After going through the steps the system should be all set to send real invoices.

In the payment module, add a payment acquirer step and add it to the invoice onboarding panel.

task: 60668
[MOV] (website_)payment: move customer portal for payments to payment 2017-08-08T13:38:04+00:00 Thibault Delavallée tde@odoo.com 2017-08-08T13:37:24+00:00 79f362d067fd34f05e7383ab0796bdd7cf325079 Customer portal controller and templates contained in website_payment module are moved to payment. This module now uses the customer portal defined in portal module and most of website_payment code is moved to payment. website_payment now contain code really related to website, such as payment acquirers configuration for website. 
Customer portal controller and templates contained in website_payment
module are moved to payment. This module now uses the customer portal
defined in portal module and most of website_payment code is moved
to payment.

website_payment now contain code really related to website, such as
payment acquirers configuration for website.
[FIX] Various P3-related import changes 2017-04-28T07:06:53+00:00 xmo-odoo xmo@odoo.com 2017-04-28T07:06:53+00:00 b4429c2a91889bf60b56e0c7909c844d357363f7 * LDAP import: python-ldap is not python3-compatible, pyldap is Warning: only supported from debian Stretch (current testing)? https://packages.debian.org/search?searchon=names&keywords=pyldap * implicitly relative imports * imports of moved or removed stdlib modules issue #8530 
* LDAP import: python-ldap is not python3-compatible, pyldap is

  Warning: only supported from debian Stretch (current testing)?
  https://packages.debian.org/search?searchon=names&keywords=pyldap

* implicitly relative imports
* imports of moved or removed stdlib modules

issue #8530
[LEGAL] Use global LICENSE/COPYRIGHT files, remove boilerplate text 2015-06-02T01:16:04+00:00 Olivier Dony odo@openerp.com 2015-06-01T22:39:30+00:00 0bd454534818941bc3216025ebe3dcac3d78c19d - Preserved explicit 3rd-party copyright notices - Explicit boilerplate should not be necessary - copyright law applies automatically in all countries thanks to Berne Convention + WTO rules, and a reference to the applicable license is clear enough. 
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
  automatically in all countries thanks to Berne Convention + WTO rules,
  and a reference to the applicable license is clear enough.
[RENAME] payment_acquirer_* -> payment_ * 2014-01-22T17:57:02+00:00 Thibault Delavallée tde@openerp.com 2014-01-22T17:57:02+00:00 0b69bad9968ce2650f6dffd7df703cd33e7f38af bzr revid: tde@openerp.com-20140122175702-1h1e51z4njt4s70w 
bzr revid: tde@openerp.com-20140122175702-1h1e51z4njt4s70w