- 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
- On 'website_payment/pay' if the reference contains a '/' the payment will never succeed.
It is due to the fact that in the template "payment.pay" were setting "prepare_tx_url" and "form_action" using this reference.
But having a '/' in the reference breaks the URL to call to create a transaction.
So when creating a transaction (or even paying in S2S) the payment never succeed and returns a HTTP 404 error.
Purpose
=======
It looks a little to restrictive to only allow bank journals on payment acquirers.
For example on could want to define a manual payment acquirer linked with a journal of type "cash".
Allow both journal types instead of only bank.
The generic payment form introduced in 11.0 has changed the way we collect payment and so does the code.
The route /website_payment/pay hasn't been changed to support the new payment form.
This commit fixes this.
It also fixes a bug for when a customer tries to create two transactions with the same reference.
As some flows were broken, this set of fixs improve the different routes for all acquirers
See commit messages for more information
Thanks to @jpr-odoo for his first implementation and to @tde and @fgi
WARNING: To avoid breaking any configuration in stable (11.0), the template payment_confirmation_status has been replicated in each module.
They must be removed before a forward-port in master
If the user has no Zip code, country or city, authorize refuse the payment, but Odoo doens't show any error.
The commit invite the user to log in in this case or to fill his missing information
The different fields weren't correctly checked on a payment form. This commit improve the error messages and display it for each field. It adds too a verification on the fields in the case of the field are filled automatically by Firefox on a refresh (F5).
Code to thumbnail payment icon image had an error for python3 because
from RPC the image would be a text string instead of an expected
bytestring.
This change accepts both and made another small fix in the view since
image_medium doesn't exist (and image is already thumbnailed).
A third fix was that removing an image caused an error.
opw-803722
closes#22088
When installing a payment acquirer from the kanban view, this would by
luck display the form view correctly.
But if we go back to the listing then forward to the form view, things
go awry.
This is because the listing action views have not been updated after the
module installed, this worked at install because we loaded a new action.
This commit change the action so when installing a payment acquirer from
the kanban view, the view is simply reloaded.
opw-786454
closes#21757
Odoo Translation Bot