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>
Martin Trigaux