- payment.acquirer have many fields with 'required_if_provider'
attribute and while saving form it gave an error like "Required
fields not filled", so it was confusing to know which required fields were empty.
- after this commit, it is displayed like "Required fields not filled (field name)"
opw:1881054
Before this commit, when authorize (for example) returned a business error
the error wasn't displayed to th ecustomer
After this commit, it is.
OPW 1866408
closes#26279
Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
The `pre_msg` field was removed from the payment process in commit
14081b848f. We hide the field since it is confusing for end users. A
proper refactoring will be done in master.
opw-1849413
The field `transactionReference` of Sips must contain only
alphanumerical characters. Previous commit 31dc6b888e solved
the special case of several attempts to pay, but a much simpler case may
appear in v11. Paying an invoice is likely to fail since the reference
contains by default `/`.
In the previous commit, we could simply modify the common `payment`
module code. In this specific case, however, we only change the
reference if the acquirer is Sips.
opw-1841483
This commit adds the auto-creation journal for installed acquirers.
This is not easy because:
- The acquirers are created on the 'payment' module but are enabled only when the specific module
is installed. E.g. Paypal is enabled with 'payment_paypal'.
- To create a journal, a chart of accounts is required. However, the post_init_hook on the
'account' module makes the installation order harder. E.g install payment_paypal directly:
The module are installed in the order: account -> payment -> payment_paypal -> l10n_generic_coa.
To fix the problem, the journals are created at two moments:
- During the installation of the chart of accounts.
- At the installation of an acquirer module. E.g. payment_paypal.
Was PR #23904
Was task: 1831620
- Fix an issue where the transaction were always set a 'form_save' thus always creating payment tokens.
- Fix an issue where when the customer paying while not being logged in was crashing.
The issue is due to the fact that we are creating payment transactions linked to no partners, doing so it crashing the code when creating the payment token with no partner set.
Before this commit, error handling would not work for non s2s payment acquirer
since it would always check for `o_payment_add_token_acq_[id]` in the DOM but
this is only present for s2s acquirer.
Non s2s acquirer got `o_payment_form_acq_[id]` in the DOM.
Now, we retrieve the correct DOM element depending if s2s is enabled for this
payment acquirer or not.
task-1825701
Until now invoice_id is filled on the transaction only when we make
payments through invoice. However if we make payments through sale order
then invoice_id is not filled.
This commit fixes that issue. As there is no common point between
sale_payment and account_payment except payment, a void method is added
in payment and an override done in account_payment. That was when both
modules are installed code is correctly triggered.
This commit is related to task ID 1813602. Closes#22746 .
- The payment template is overwriting the return url which caused it to be never valid.
This is mainly used by payment that uses 3D Secure.
If the return_url doesn't exists, then the customer is redirect to '/' which is not what we want.
If the payment doesn't use 3D Secure, then the controllers that handle it may (and it is always the case) redirect the url to a hardcoded url inside it.
This was already the intended behavior, but in Python a return inside
of a try...finally does not behave this way. From the Python
documentation [1]:
When a return, break or continue statement is executed in the try
suite of a try...finally statement, the finally clause is also
executed ‘on the way out.’
This can cause issues because some payment acquirers will return an
error when refunding a pending transaction. This puts the transaction
in the 'error' state which means it won't be refunded anymore.
Additionally, putting s2s_do_transaction in a try...except like this
hides any traceback that occurs which makes troubleshooting harder.
[1] https://docs.python.org/3/reference/compound_stmts.html#finally
When making a payment with authorize.net by clicking on "Pay Now" in the shop, it was
possible to send several transactions for the same SO because the button "Pay Now"
was enabled before being redirected.
opw:1819588
Steps to reproduce the bug:
-Just purchase a simple product using Authorize.net
-Click on "Pay Now" to be redirected to Authorize.net gateway
Bug: The company field added during checkout page was not filled.
opw:1817597
Odoo Translation Bot