This commit adapts the business code in which
class/module/function/method redefinition took place so that it no
longer happens and the pylint test passes.
- Install 3 payment providers:
P1: no countries set
P2: country set to USA
P3: country set to Canada
- Activate online payment of invoices
- Create an invoice for portal user A (country of user is USA)
- Login with A
- Pay the invoice
All 3 providers are available, while only 1 & 2 should be available.
The providers are filtered in the sale module, but not in the account
module:
https://github.com/odoo/odoo/blob/586ee04a6296c13868011b3afaca61be5c6ff3c6/addons/sale/controllers/portal.py#L190-L193
The same issue occurs with the direct link `/website_payment/pay`.
We apply the same filtering in all modules.
opw-2279710
closesodoo/odoo#53483
X-original-commit: aaac93b551e2a5f331dd14ee5aefbe4ced173691
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Have the main company (A) with the public user
Have an invoice in company B
Make a brand new browser access the invoice with the token
Before this commit: the token link ended up asking the customer to login,
eventhough it wouldn't if the invoice were in company A
After this commit: the whole payment with access token flow works as expected.
OPW 1879999
closes#26744
- When paying an invoice with a payment acquirer that saves tokens after each payments (S2S mode or save token to "ask" or "always") and while not connected.
The payment token is saved as either the invoice partner (when the acquirer is in form mode) or as the public user's partner (for S2S acquirers).
This should not happen.
To fix this issue, if the customer is not connected and pays the invoice using a form acquirer, we do not create a token.
If the customer pays the invoice using a S2S acquirer the created token is then linked to the invoice's partner.
This commit adds support of payment in the account customer portal. This
is done in the account_payment module. This way customers can now pay
invoices directly on the customer portal and have access to the status
of their invoices. It replaces the old website payment mechanism that
was only allowing to pay without generating payments and reconciliating
them.
Two routes are defined in this commit, one for form-based payments and
one for server2server-based payment. Please refer to commit 1fdb10f0ac
for more details about the new payment form.
Tools methods are added to handle transaction / invoice matching, the
check of invoice and the automatic payment and reconciliation.
Adrian Torres