Defined as this, the label of the selection field were translated during code
import, when building the python model, not when a user access the field values
as it should (and is already the case thanks to the ORM).
Trying to translate a string when no user-context is available is not only
useless but may cause bug on services with multiple databases (e.g. a SaaS).
In a multi-worker environment, when the code is imported, the _ method will use
multiple scenarios to detect the language and get a cursor.
As we have no available cursor in the frame (method _get_cr from GettextAlias),
the fallback is made on the cursor of the request.
In a multi-worker environment, this could be a cursor linked to a database in
another language than English.
In such scenario, the selections would be translated in the language of the
other database instead of displaying it in English
opw-1881956
Mercury can partially approve transactions in case a card does not
have enough credit available to cover the full amount.
Before this the payment amount was kept as the full purchase amount
leading to a difference between what Mercury charged and what Odoo
registered as charged.
opw-1840946
Due to historical reasons the amount on a statement line is used to
find it again so the credit card information can be added to it.
Doing a search directly on 'amount' will fail in rare cases when
the currency rounding doesn't result in a float with the same amount
of decimals as the rounding specifies. E.g.:
>>> currency = env['res.currency'].browse(3)
>>> currency.rounding
0.01
>>> currency.round(74.85000000000001)
74.85000000000001
When that happens the credit card information is not saved in the
backend. To avoid this we do the float comparison properly with
float_compare afterwards.
PS. Ideally the logic in add_payment should be moved to an override of
_prepare_bank_statement_line_payment_values. This way we wouldn't have
to do these awkward things to find the statement line. But this
approach is not suited for a stable release.
opw-1832156
It used to be possible to run test transactions against mercurypay.com
using a regular swiper device, test credentials and test cards
provided by Mercury.
Mercury has recently disabled this saying this feature did not adhere
to certain PCI regulations.
It means that currently on the regular mercurypay.com network only
real cards (and thus real money) can be used.
Because we require a way to test without spending money this commit
allows to switch to the test network (mercurycert.net). It uses a
system parameter because we cannot introduce a Boolean on
pos_mercury.configuration in a stable release. It also changes the
test credentials to some that work on mercurycert.net.
Note that the regular 'production' swiper devices can not be used on
this test environment. This results in:
Error 004118: Failed to decrypt
The swiper contains embedded cryptographic keys specific to
mercury*pay*.net. Instead a specific 'development' swiper device with
embedded keys for mercurycert.net is required.
opw-1832156 (this is necessary to test that issue)
Normally Vantiv should return an 'Invalid Purchase Amount' error. But
sometimes they will process the transaction anyway as if it had a
positive amount. We're sure the amount we send is negative. After
communicating with Vantiv it's unclear why that sometimes
happens. They recommend to explicitly prevent negative charges and to
not rely on them throwing an error.
Since we have to display an error message to the user anyway we take
the opportunity to explain the correct full flow to handle refunds.
opw-805302
Odoo Translation Bot