createTransactionRequests can return responses like this:
{'messages': {'message': [{'code': 'E00027',
'text': 'The transaction was unsuccessful.'}],
'resultCode': 'Error'},
'transactionResponse': {'SupplementalDataQualificationIndicator': 0,
'accountNumber': 'XXXXXXXX',
'accountType': 'eCheck',
'authCode': '',
'avsResultCode': 'P',
'cavvResultCode': '',
'cvvResultCode': '',
'errors': [{'errorCode': '33',
'errorText': 'Bill To Address is '
'required.'},
{'errorCode': '33',
'errorText': 'Bill To State/Province is '
'required.'}],
'refTransID': '',
'responseCode': '3',
'testRequest': '0',
'transHash': '',
'transHashSha2': 'xxx',
'transId': '0'}}
_make_request() threw out the detailed errors ("Bill To Address is
required" and "Bill to State/Province is required") and only returned:
{
'err_code': 'E00027',
'err_msg': 'The transaction was unsuccessful.'
}
which results in the following vague error on an SO:
The transaction with reference SO1111/1111111 for US$ 100.00
encountered an error (Authorize.net). Error: Authorize.Net: Received
data with status code "3" and error code "The transaction was
unsuccessful."
This commit extracts the transaction errors and appends them to
'err_msg'. After this commit the above response results in this chatter:
The transaction with reference SO1111/1111111 for $ 100.00
encountered an error (Authorize.net). Error: Authorize.Net: Received
data with status code "3" and error code "The transaction was
unsuccessful. Bill To Address is required. Bill To State/Province is
required."
Ideally the error handling logic would be rewritten so that
_make_request() doesn't handle specific errors like this. But changing
it is too high risk in a stable release.
opw-2718318
closesodoo/odoo#82443
X-original-commit: c7b292f7b86679b11527a68093ed70b36dc2fd1a
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
A company name >50 chars leads to:
Authorize.Net: Received data with status code "3" and error code "The
'AnetApi/xml/v1/schema/AnetApiSchema.xsd:company' element is invalid -
The value XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX is
invalid according to its datatype 'String' - The actual length is
greater than the MaxLength value."
This limits the company name to the specified 50 chars [1][2]. Cutting
off the company name should be fine for the same reasons as outlined in
64b86f36264c2e655681c7b6bed69e89891107bf.
[1] https://developer.authorize.net/api/reference/index.html#payment-transactions-charge-a-credit-card
[2] https://api.authorize.net/xml/v1/schema/AnetApiSchema.xsd
opw-2725246
closesodoo/odoo#82171
X-original-commit: 412e50290524ed0edc0317b141a296a883b173d3
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The logs for payments contain the transaction reference whenever possible.
Before logs for transactions contained the reference or the id of the
transaction in an inconsitent way. No transactions are identified by
reference whenever possible.
The logs for payments for the same function on different acquirers should
have the same format. Same flow step for different acquirers had
information passed in different formats. Now at each step of a transaction
flow log messages have the same format regardless of the acquirer.
Overall the payment logs should have an uniform format. Hopefully
understanding log messages related to transactions should be easier, as
now log format is independent of the acquirer and transaction are easily
identified by reference.
Task - 2545450
closesodoo/odoo#79547
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The maximum length for nameOnAccount is 22 characters [1]. Entering a
longer name results in an unclear error message:
Server Error
We are not able to process your payment.
E_WC_26: Please provide valid account holder name.
A maxlength="22" on the input was considered as well, but it would be
confusing for users and bank transactions with the first 22 characters
should be accepted.
opw-2688384
[1] https://developer.authorize.net/api/reference/features/acceptjs.htmlclosesodoo/odoo#79950
X-original-commit: 64b86f36264c2e655681c7b6bed69e89891107bf
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: jorenvo <jov@odoo.com>
- This replaces the name of `refund_amount` to `amount_to_refund`
for a variable that was renamed elsewhere, which caused a traceback.
- Adyen and authorized `_send_refund_request` now have their return,
as their parent.
- When a refund is initiated from Adyen, it's now easier to change
the merchant reference, thus, we can't count on it anymore to get
the source transaction.
- Fix the automatic refund for authorize.net with the manual capture
task-2634184
closesodoo/odoo#77916
X-original-commit: 747dbf44f37407fd415af645dac652199ac7fa6b
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
It's possible for a payment.acquirer to charge tokens when it's
disabled via the subscription app (_cron_recurring_create_invoice()).
Before this patch it would use the production endpoint. It's
unexpected and can cause accidental charges in a database meant for
testing.
opw-2637659
closesodoo/odoo#76820
X-original-commit: 7316413261ca8294ceffa212d6b5079b6e35daf6
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before 660dc0ebaf it was possible to use Authorize to pay via your bank
account using the "Redirection to payment acquirer" option. Since the
refactor removed the redirect it was no longer possible. This commit
reintroduces that feature.
It does so by adding new form elements that accept bank account
information. Additionally it reintroduces the `billTo` and `customer`
parameters that Authorize requires when processing ACH payments.
task-2628318
closesodoo/odoo#75289
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Before this commit, it was not possible to refund a payment from Odoo.
Users had to go through the payment acquirer's backend and update the
payment accordingly in Odoo.
With this commit, refunds are made available in Odoo directly from the
payment form, for acquirers that support them. Acquirer can either only
support full refunds or also support partial refunds.
As of now, the only acquirer allowing refunds is Adyen, with partial
refund support.
task-2527891
closesodoo/odoo#70881
Related: odoo/upgrade#2689
Related: odoo/enterprise#19829
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Fix two issues:
The search of suitable payment token was searching on the journal_id
field of the payment acquirer that is no longer stored.
Change it to now search on the acquirer_id directly, since we have
this information.
The _inverse_journal_id method on payment acquirers would create
new payment line with the manual payment method when no provider
are given to an acquirer, or no payment method is existing for
a given provider. This would cause issues with the creation of
multiple line with the same name on a same journal, which would
trigger the constrains blocking that.
closesodoo/odoo#74990
X-original-commit: a3a2fcb0b299fafbf359ec9015da5c85cdb57b3a
Related: odoo/enterprise#20193
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, the validation flow with verification (payment of a
small amount with immediate refund) was performed with the use of
validation routes: after payment, the customer was redirected to the
validation route stored on the transaction to trigger the refund. This
implementation had an issue: if the customer never reached the
validation route, they were not refunded their validation amount. This
could happen if the customer closed the tab after paying with an
acquirer offering payments with redirection, or if the validation
payment was asynchronously confirmed through a webhook notification.
This commit gets rid of validation routes and requires acquirers to
immediately refund the validation amount when the payment is confirmed.
This way, a payment confirmation coming from a webhook can trigger the
refund too.
As the only acquirer that implements the validation with verification
flow, Authorize.net now voids validation transactions as soon as they
are authorized.
While we're at it, the logging of processing values is adapted to only
log specific rendering values if a redirect form is rendered.
task-2612977
closesodoo/odoo#74707
Related: odoo/enterprise#20060
Related: odoo/upgrade#2710
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
As validation transactions are authorized rather than captured, they are
refunded with a void request. Before this commit, a voided validation
transaction was mistakenly flagged as canceled while it should have been
confirmed.
This commit makes the distinction between a voided regular transaction
and a validation transaction.
task-2612977
closesodoo/odoo#74581
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
_prepare_transaction_request() introduced in
35a6c1867d8edc9b58c002a6ff6a63c35a0fc708 is only used for
'authOnlyTransaction' and 'authCaptureTransaction' transaction
types. capture(), void() and refund() still build their own request
parameters. Make this clearer by renaming _prepare_transaction_request()
to _prepare_authorization_transaction_request().
closesodoo/odoo#73373
X-original-commit: da00ae85f69cfde217d09b93113f8b7821aabff2
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This makes it possible to patch only _prepare_transaction_request in
case parameters need to be added.
closesodoo/odoo#73215
X-original-commit: 35a6c1867d8edc9b58c002a6ff6a63c35a0fc708
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
Following the recent reorganisation of the documentation in 12.0+,
the majority of the documents have been moved and their old links are no longer valid.
Some redirection rules will soon be deployed, but those rules might be dropped in some years
and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closesodoo/odoo#70920
X-original-commit: bc9c1eef538ba6095e74c19d5d9ed9e01625ec7c
Related: odoo/enterprise#18361
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit will add the needed ESLint configurations on the JS files.
These configurations are added if the JS file uses a different
environment (serviceworker, node, etc) or if it uses a specific global
(google, ace, etc).
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
This commit also drops the payment with redirection flow in favor of
the direct payment flow only, while preserving the currently used APIs.
See the merge commit for more details.
task-2333030
Co-authored-by: Adrien Horgnies <aho@odoo.com>
Steps:
- Install website_sale and payment_authorize
- Set up a tunnel (e.g. ngrok)
- Log in to Authorize.Net backend
- Go to Account > Response/Receipt URLs > Add Url
- Enter the tunnel URL
- In Odoo, go to Website > Configuration > eCommerce > Payment Acquirers
- Edit "Authorize.Net"
- Credentials tab:
- State: Test Mode
- API Login Id, Transaction and Signature key
- Save, then Generate Client Key
- Configuration tab:
- Payment Flow: Payment from Odoo
- Stop the server
- Replace https://github.com/odoo/odoo/blob/1b9b99dc2643910c1412b564affccf02ba1e55d9/addons/payment_authorize/models/authorize_request.py#L46 with `resp = {'messages': {'resultCode': 'Error', 'message': [{'code': 'E00027', 'text': 'An error occurred during processing. Call Merchant Service Provider.'}]}}`
- Restart the server
- Go to "Website" > "Go to Website" > Shop
- Add a product to the basket
- Check out the basket
- Choose "Credit Card (powered by Authorize) Test Mode"
- Pay Now
- Enter any card data (e.g. 4111 1111 1111 1111 - 01/22 - 900)
Bug:
When the Pay Now process is done, the customer is redirected to
`/shop?error=invalid_token_id`. No errors are shown.
Explanation:
The patch simulates an error from Authorize.Net happening during their
process. Using the special card numbers won't trigger the wanted
behavior.
When getting an error from Authorize.net, a `UserError` is raised. This
error is then caught in the controller to return a formatted message.
However, returning a dict in this part of the code embeds it inside
`{'result': [...]}`. The error message is, thus, not blocking the form's
redirection and the user gets redirected to the form action, i.e.
`/shop/payment/token`. This route requires `pm_id`, but, in this
scenario, it's an empty string. This leads to another redirection to
`/shop/?error=invalid_token_id` as seen here:
https://github.com/odoo/odoo/blob/1b9b99dc2643910c1412b564affccf02ba1e55d9/addons/website_sale/controllers/main.py#L938-L941
Letting the error bubble up forces the backend to return a blocking
error response. This makes the fronted display the Authorize.Net error
underneath the provider selection, and prevents it from redirecting.
opw:2419260
closesodoo/odoo#64482
X-original-commit: 2636b9f5059808b443be67b06fca129cf9d3a913
Signed-off-by: backspac <backspac@users.noreply.github.com>
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
closesodoo/odoo#61449
X-original-commit: 3a220d3ad2999a21d54924940574ba96a9c07154
Signed-off-by: jorenvo <jorenvo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Closing the Authorize.net popup with the little "x" doesn't call the
responseHandler. Looking at the documentation (and source) of
AcceptUI.js it seems there's no clean way to detect this.
Because of this the "Pay & Confirm" button remains disabled, requiring
the user to refresh the page.
To solve this don't disable the button at all. Presumably it was added
to avoid issues when spamming the button with clicks on a slow
connection. But simulating this with a slow connection doesn't cause
any issues.
When AcceptJS is not yet loaded it's loaded with web.ajax.loadJS(). It
correctly handles parallel calls before loading is finished and
returns the same promise. AcceptJS correctly ignores subsequent click
events on the button, because it immediately blocks all clicks on the
body (and grays it out).
Using a MutationObserver was also considered but this approach is much
less messy.
opw-2367166
closesodoo/odoo#60870
X-original-commit: 63f759b63284efc5fb9f5dc7dfbe4e2aed982ad0
Signed-off-by: jorenvo <jorenvo@users.noreply.github.com>
Without this you have to overwrite the entire function.
closesodoo/odoo#57696
X-original-commit: c2e980c3798c3cf75e4f96b71c7bc81dbad6b78c
Signed-off-by: jorenvo <jorenvo@users.noreply.github.com>
The purpose of this task is to improve the UI of the 'Apps', by
improving the clarity of the kanban, sequencing the apps and
simplifying the app categories in the searchpanel
So in this commit, Added the new sequences for ir.module.module
and ir.module.category records.
TaskID: 2240257
Related Enterprise: https://github.com/odoo/enterprise/pull/12413Closes: #55907
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
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).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
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
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The `payment` module introduces a certain amount of payment acquirers,
each one corresponding to a `payment_` module.
When a `payment_` module is installed, this data is updated so that
payments done with the corresponding acquirer change in behaviour using
the provider installed by the `payment_` module.
When a `payment_` module is uninstalled, this data should be reset to
default, more especifically the `view_template_id` and the `provider`
fields of `payment.acquirer`.
This was not possible before this commit, and more importantly it would
make the uninstallation of such `payment_` module impossible as the
`view_template_id` is a required m2o ondelete='set null', which will
make the registry crash. Even if the former wasn't a problem, the
provider field would remain set to a non-existing selection option,
which would make the registry crash (eventually, when checking a record
with such a selection option).
With this commit, we reset these fields to their default value upon
module uninstall.
In 13, the issue with `view_template_id` should be fixed, as required
m2o that are ondelete='set null' are no longer possible. As for the
provider Selection field, a fix should arrive in master soon.
opw-2225333
closesodoo/odoo#48916
X-original-commit: 4f0c1c1bfd71dd1ff6793d0a91b49984c54d1351
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
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.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
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>
Joren Van Onder