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
closesodoo/odoo#48420
X-original-commit: 034c04efa4ccecd40f657eae97ef2b04934d570c
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- 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
closesodoo/odoo#46206
X-original-commit: ae3885295795f8c150bd40af266004016fd300c5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
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
<Restart odoo>
>>> 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
closesodoo/odoo#45362
X-original-commit: 7485927f0eb152086efcaaf4a30260e503267c41
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
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 26f3d8465d.
opw-2188889
closesodoo/odoo#45259
X-original-commit: d269bba3b9f4f4fa567a2a7084396bdf08422fa4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
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
closesodoo/odoo#39643
X-original-commit: a9fb15b33fd041ee420581a5ba450017db06e0c7
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The authorize payment API has deprecated their md5 based authentication
in favor of sha512. The `test_10_Authorize_form_render` test was failing
due to no-more-valid tests inputs.
As the `payment.transaction._authorize_form_validate` method verify the
status of the transaction before validating the form thank to 01216345,
calling `_set_transaction_done` is no more valid thus has been removed.
The reference has been changed due to the same commit.
closesodoo/odoo#36139
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
PURPOSE
Test frontend and UI tools of eLearning.
SPECIFICATIONS
Recent commit 5193f0d010 introduced a tool method to parse errors and ease
their management. A variable typo was done by mistake, fixed in this commit.
LINKS
Task ID 1937768
closesodoo/odoo#36085
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Replace website_published and environment by a generic state on
payment.acquirer
Payment acquirers aren't enabled by default. When setting their state to 'enabled' or 'test', it is verified the required fields for the provider are set.
add accept js of authorize.net to make s2s flow pci compliance
after clicking on pay now button, one popup display with card inputs
popup is provided by a authorize with all validation facilities
After submitting details, payment flow is
- get the temp token information from authorize
- create a token with that temp token information in odoo
- make a request to authorize for charge
- after successful request, payment will be charged for that card
task- 2025821
- convert XML format request to JSON
- remove refund method from the request, as there is no use of it,
we will never validate card as authorize.net validate card by itself,
so there is no case for the refund
- verify token while creating it
- make verify validity field invisible in case of authorize
task- 2025821
The big images are probably never going to be used for the following models:
- pos category
- fleet brand
- livechat channel
- mail channel
- payment acquirer
And if big images are needed some day the model should use image.mixin instead.
PR: #34925
This commit extends the changes introduced by 88de93114 to adapt
Odoo payment flows to the switch in transaction signature done
by Authorize.net.
The initial fix was not sufficient for flows that mixed redirection
payment flows and server-to-server flows (e.g. paying a quote with a
card that gets saved then using the token to pay for a subscription).
The problem comes from the fact that the server-to-server API uses
the API Transaction Key and API Login ID as credentials to authenticate
requests; there is no need for a signature since this data is never
publicly exposed on the website and a MITM is mitigated by the fact
that it would need to be done between the Odoo server and the
Authorize.net servers (both of which use https in a normal deployment)
which is admitedly more complex than doing a MITM on a Starbucks wifi.
On the other hand, the 'redirection' flow will include all transaction
parameters as inputs in an html form, therefore the signature is
required to ensure that the values have not been modified by a website
user or a mitm.
Since both flows can coexist on the same configuration, we cannot use
the same field depending on the payment flow configuration - we need
both fields to be stored for the provider.
This commit therefore has to introduce new fields on payment.acquirer
record that can store the signature key for authorize in addition to the
usual authorize fields. Instead of adding a new module, this commit uses
non-stored computed fields that will generate System Parameters entries
for any acquirer of the 'authorize' kind when set through the interface.
closesodoo/odoo#34670
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
The callback will usually check the transaction's state during
its execution, hence it should be executed after the state change
closesodoo/odoo#34666
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
https://docs.python.org/3/library/stdtypes.html#truth
By default, an object is considered true unless
its class defines either a __bool__() method that returns False
or a __len__() method that returns zero
Since etree elements are iterator, they define a len function.
However it turns out that customerProfileId has always no children.
So bool(find(x)) is always False; the intended meaning was find(x) is None.
opw 1999427
closesodoo/odoo#34922
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Damien Bouvy