Odoo/addons/payment_authorize/models, branch 14.0

[FIX] payment_authorize: send the full reference for s2s transactions

2021-01-05T01:09:47+00:00

invoiceNumber is limited to 20 characters so if the reference in Odoo
is longer we send an incomplete reference. This makes it hard to match
up S2S payment.transactions in Odoo with their counterparts in the
Authorize.net portal.

To solve this send the full reference in the description field (which
has a max length of 255 characters [1]).

[1] https://developer.authorize.net/api/reference/index.html#payment-transactions-charge-a-customer-profile

closes odoo/odoo#64119

Signed-off-by: jorenvo

[FIX] payment_authorize: support references longer than 20 characters

2020-11-05T18:15:23+00:00

We can have payment.transaction references of >20 characters. This
happens automatically if you have long sale.{order,subscription}
sequences (especially through website_payment because it adds multiple
suffixes, e.g. SO2020/1234567 could turn into
SO2020/1234567-12-1-1-1). We POST the full reference via the
x_invoice_num variable. Unfortunately Authorize specifies a maximum
length of 20 for this field [1]. So when Authorize POSTs back to
/payment/authorize/return it only specifies the first 20 characters in
x_invoice_num. E.g. when POSTing

{
...
'x_invoice_num': 'SO2020/1234567-12-1-1-1',
...
}

we receive back in /payment/authorize/return:

{
...
'x_invoice_num': 'SO2020/1234567-12-1-',
...
}

This causes _authorize_form_get_tx_from_data() to not find the
transaction which results in a ValidationError.

To fix this also pass the reference in the x_description field. It has
a more generous 255 character limit [1]. Then search using both.

We can't get rid of x_invoice_num entirely because we cannot assume
the payment_authorize.authorize_form will be updated (even more so
because it's a noupdate="1" template). By still using it in
_authorize_form_get_tx_from_data() we ensure that everything keeps
working regardless of whether or not x_description is included in the
template.

[1] p39 in https://www.authorize.net/content/dam/anet-redesign/documents/AIM_guide.pdf

opw-2373433

closes odoo/odoo#61446

X-original-commit: 3a220d3ad2999a21d54924940574ba96a9c07154
Signed-off-by: jorenvo 
Signed-off-by: Nicolas Martinelli (nim)

[FIX] *: correct all or improve code translation lookup

2020-06-30T10:19:59+00:00

This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
  _("Foo %s", bar)

to progressively migrate the code to the new syntax.

A few calls were not technically incorrect but still detected by the
linter.

  _("Foo" +
    "Bar")

has been converted to

  _("Foo"
    "Bar")

as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).

closes odoo/odoo#53683

Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco)

[FIX] payment_authorize: display errors to customers

2020-04-22T16:54:27+00:00

Set the transaction to the state 'error' when Authorize.net responds
with that status, as it will display a message to the customer to detail
the problem.

opw-2231276

X-original-commit: 005607fce4a22394a9f67cc4eaa52f8bf89780f0

[FIX] *: set ondelete policy of required Selection fields

2020-03-30T13:42:04+00:00

With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.

This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.

closes odoo/odoo#46325

Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco)

[FIX] payment_authorize: include phone in customer profile

2020-03-26T10:57:20+00:00

It is possible to define required fields from the Authorize.net backend
without which no customer profile can be created. These fields include
data that Odoo sometimes does not have at all (fax number, anyone?);
however including the phone number is a meaningful option.

Before this commit, if the 'phone number' was required by the
Authorize.net configuration and was correctly set in Odoo, this still
did not work because we did not include the phone number with the
customer profile creation request payload.

We do now.

opw-2215332

closes odoo/odoo#48420

X-original-commit: 034c04efa4ccecd40f657eae97ef2b04934d570c
Signed-off-by: Damien Bouvy (dbo)

[FIX] payment_authorize: change order of keys

2020-02-25T10:34:36+00:00

- Select 'capture manually' in Authorize.net Payment acquirer
- Do an online transaction
- Click on the Capture button at Payment transaction windows.

An error message is returned:

The element 'transactionRequest' in namespace
'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element
'amount' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List
of possible elements expected: 'splitTenderId, order, lineItems...'.

This because the keys `amount` and `refTransId` are inverted in
`createTransactionRequest`:

https://developer.authorize.net/api/reference/index.html#payment-transactions-capture-a-previously-authorized-amount

A simple fix is to swtich them. Indeed, the Odoo 13.0 requirements is
Python 3.6+, in which the keys order at iteration is the insertion
order. Although this was officially part of the specification in 3.7,
the change is already available in 3.6.

Closes #45891
opw-2201667

closes odoo/odoo#46206

X-original-commit: ae3885295795f8c150bd40af266004016fd300c5
Signed-off-by: Nicolas Martinelli (nim)

[FIX] payment_authorize: always send an amount with the correct decimals

2020-02-14T08:44:12+00:00

We cannot assume reading the value of a monetary field has the
decimals specified by the currency in decimal_places.

Right after creating a record with a monetary field it may have a
different amount of decimals.

To reproduce this:

>>> tx = env['payment.transaction'].create({
   'amount': 10.87,
   'acquirer_id': env['payment.acquirer'].search([], limit=1).id,
   'currency_id': env.ref('base.USD').id,
   'reference': 'test'
})
>>> tx.id
130
>>> tx.amount
10.870000000000001


>>> env['payment.transaction'].browse(130).amount
10.87

Authorize requires us to send a correctly rounded amount. The
following response is returned when sending 10.870000000000001:

{'messages': {'message': [{'code': 'E00027',
                           'text': 'The transaction was unsuccessful.'}],
              'resultCode': 'Error'},
 'transactionResponse': {'SupplementalDataQualificationIndicator': 0,
                         'accountNumber': '',
                         'accountType': '',
                         'authCode': '',
                         'avsResultCode': 'P',
                         'cavvResultCode': '',
                         'cvvResultCode': '',
                         'errors': [{'errorCode': '5',
                                     'errorText': 'A valid amount is '
                                                  'required.'}],
                         'refTransID': '',
                         'responseCode': '3',
                         'testRequest': '0',
                         'transHash': '',
                         'transHashSha2': '',
                         'transId': '0'}}

To work around the issue always round when we read amount.

Lower level solutions were considered in #45248 but for now we'll
stick with this higher level and lower risk patch.

opw-2188889

closes odoo/odoo#45362

X-original-commit: 7485927f0eb152086efcaaf4a30260e503267c41
Signed-off-by: Nicolas Martinelli (nim)

[IMP] payment_authorize: log API responses

2020-02-13T08:16:01+00:00

Makes debugging possible without having to run the db locally and
manually adding _loggers everywhere.

Parts of the error are logged already, leading to messages like:

...payment_authorize.models.payment: The transaction was unsuccessful

Unfortunately they don't show the reason. The entire response is
something like:

{'messages': {'message': [{'code': 'E00027',
                           'text': 'The transaction was unsuccessful.'}],
              'resultCode': 'Error'},
 'transactionResponse': {'SupplementalDataQualificationIndicator': 0,
                         'accountNumber': '',
                         'accountType': '',
                         'authCode': '',
                         'avsResultCode': 'P',
                         'cavvResultCode': '',
                         'cvvResultCode': '',
                         'errors': [{'errorCode': '5',
                                     'errorText': 'A valid amount is '
                                                  'required.'}],
                         'refTransID': '',
                         'responseCode': '3',
                         'testRequest': '0',
                         'transHash': '',
                         'transHashSha2': '',
                         'transId': '0'}}

Since we log the full request above, let's also log the full response.

PS. this was present before but was lost with 26f3d8465d3c6f1da80c186.

opw-2188889

closes odoo/odoo#45259

X-original-commit: d269bba3b9f4f4fa567a2a7084396bdf08422fa4
Signed-off-by: Nicolas Martinelli (nim)

[FIX] payment_*: multiwebsite base_url

2019-10-31T12:33:56+00:00

Fine-tunning of 937b5c076e7175bec664ed0cf4b77505e342f1e2

Have a multiwebsite setup
have a payment installed for one of the two websites

Make an order on that website and try to pay

Before this commit, the transaction doesn't come back to odoo's
payment success controller
This was because the return url was set to the web base url ICP

After this commit, the payment success page is opened as we took
the request's url as the return url

opw-2080352

closes odoo/odoo#39643

X-original-commit: a9fb15b33fd041ee420581a5ba450017db06e0c7
Signed-off-by: Jorge Pinna Puissant (jpp)