This commit adds the possibility to define a maximum payment amount that
a given acquirer can process. If the payment amount exceeds the value,
the acquirer is filtered out of the available acquirers listed on the
payment forms.
While we're at it, the field `country_ids` is renamed to
`available_country_ids` to better depict that it is not a property of
the acquirer, but a configuration option. It will also be coherent with
the field `available_currency_ids` that is expected to be added soon.
Task - 2162165
closesodoo/odoo#82411
Related: odoo/enterprise#24412
Related: odoo/upgrade#3703
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
For payment_buckaroo and payment_sips (at least) running with a
non-standard port is an issue to the `test_redirect_form_value` tests:
while the form and test will use respectively the base_url and the
configuration port, both check a response signature which is
predicated upon a base url of `http://127.0.0.1:8069`.
This means the test does not pass when run with a different port, and
may not pass if the database was installed with a different port
either (because this may have caused the `web.base_url` to be set to
the installation port).
The other payment modules don't seem to have such signature
verification and thus apparently don't mind running with non-default
port.
Update in 15.2: `test_webhook_notification_confirms_transaction` also
broke but differently, because the payment utils would fetch (and use)
the `web.base.url` they get confused if a db is installed using one
port then the tests are run using an other (or something along those
lines), despite `HttpCase` trying to set the `web.base.url` (could be
an ordering thing).
Anyway a working solution seems to be to *remove* the bespoke code
from `PaymentTestUtils` and fix `HttpCase.base_url()` so it uses the
right port (apparently that'd never been fixed). This does require
adapting the patch being forward-ported as `base_url` is now a
callable, not an attribute.
Also re-remove the attractive nuisance of the odoo.tests.common.PORT
constant which does not work: it is evaluated before the configuration
has been loaded and is thus always set to the default (8069).
closesodoo/odoo#86068
X-original-commit: c28c99f7399da91e1a6176d6f97d4fc947013cae
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, most acquirers needed to run several successive
searches for the transaction whose reference was received by a
controller in notification data. This is because the security checks
run on the notification data require access to the acquirer through the
transaction record which was immediately discarded.
Starting with this commit, all `*_feedback_data` method are no longer
decorated with `api.model` and can use the transaction record they're
called on if provided. They are also renamed to `*_notification_data`.
task-2737144
closesodoo/odoo#83850
Related: odoo/enterprise#23938
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
An overridable model method was added in a previous commit in order to
neutralize a database.
This commit introduce the implementation of this method for the payment
modules.
Also, a `_neutralize_fields` helper method is added on the
PaymentAcquirer model to simplify the neutralization of the various
payment modules.
Part-of: odoo/odoo#67825
Notification handling in some acquirers presents a subset of the
following issues:
1. The signature of synchronous notifications (redirect payloads) is not
checked. (Alipay, Authorize, Buckaroo, Mollie, PayU money, PayULatam)
2. When the signature check fails, we raise a ValidationError which
counts as an HTTP 200 for some providers (it's not the case if they
expect a specific string). (Adyen, Paypal, Sips, Stripe)
3. If a ValidationError is raised when processing the feedback data, it
is allowed to bubble up to the provider. (Alipay, Ogone)
The issues are respectively addressed as follows:
1. If the acquirer implements payments with redirection, make sure that
if either makes a request to the provider to validate the data or
that it verifies the signature. Verifying the origin of the request
is not enough: the payload must be checked too.
2. Instead of raising ValidationError's, raise an HTTP 403 FORBIDDEN
error if the signature check fails.
3. Wrap the call to `_handle_feedback_data` of the webhook method inside
a try/except clause to catch any ValidationError, log a warning, and
acknowledge the notification to avoid having the provider disable the
webhook because of too many failures.
task-2688139
task-2693293
closesodoo/odoo#81607
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Lucie Van Nieuwenhuyze <luvn@odoo.com>
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
Some bits of code still use old variable.
Task ID 2237300
Closes PR #49462closesodoo/odoo#49501
X-original-commit: 4d402e94cb18cf5cc7e89ba9a9c305d02542a7f9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Victor Feyens