This commit aims to improve the user experience when using payment acquirers. There currently are no error feedback with some acquirers, which leaves the user wondering what is going on and what is the real status of its payment.
In some cases, the user is currently being redirected to the home page even though the payment has failed. We want to make it more obvious to the user that something unexpected has happened by redirecting to an intermediate page that will provide good feedback on payments status.
Another goal of this commit is to order acquirers by sequence instead of by flow and to select the first acquirer by default. This feature was already implmented in commit fe294fd43e521bd2d339e962f43acf46c3d4cb97, some UI adaptations were needed though.
Related to task #36680Closes#26958
`firstName` and `lastName` should be filled in for Australia, but the
implementation is not correct since:
- it assumes that the name is first name + last name, which is not the
case in all countries (e.g. France)
- it doesn't take into account that the name could be a company name
This reverts commit 26974d4e5f.
for the payment processor wespac there are required fields we do not send.
required:
•Card Number
•Expiration Date
•Amount
•First Name
•Last Name
•Address
•City
•State/Province**
•Zip Code (Postal Code/Postcode)**
•Country
•Email
** These fields are optional if the billing address is not in the U.S. or Canada. If the address is in the U.S. or Canada, the two-digit State/Province code must be provided, along with the Zip/Postal Code.
* website_sale, payment_authorize, payment_ogone, payment_stripe,
website_sale_delivery
(Many bugs were only revealed by BS4, not created)
- Align payment method (Ex.Stripe) form attributes in row.
- Fix align between radio button and payment method name.
- Removed header div from 'billing & shipping'.
- Set badges (Ex.free) and align between badges and delivery method
name in choose delivery method.
- Border subtraction from delivery methods div as already card class
has border.
Regenerate all child translations based on the .pot
Remove the terms that are either equal to the parent, either equal to the
source term.
Remove empty translation files
The system completely changed. I also had to adapt classes to new
screen breakpoints.
hidden/hide -> d-none
show -> d-block
hidden-xs -> d-none d-md-(block/inline/...)
hidden-sm -> d-md-none d-lg-(block/inline/...)
hidden-md -> d-lg-none d-xl-(block/inline/...)
hidden-lg -> d-xl-none
visible-xs-* -> d-* d-md-none
visible-sm-* -> d-none d-md-* d-lg-none
visible-md-* -> d-none d-lg-* d-xl-none
visible-lg-* -> d-none d-xl-*
hidden-print -> d-print-none
visible-print-* -> d-none d-print-*
...
and all possible combination of those had to be handled too.
According to Authorize.net documentation, the state code should only be
used for United States. For the other countries, use the state name
instead.
opw-1854278
It was very confusing for the user to distinct account.payment and payment.transaction. From now on, the transactions are
technical objects and, in the backend, we only refer to it in log messages (Front end will be adapted in the same fashion
later on). They are hidden in debug mode in accounting\configuration\payments as their purpose is now purely technical/log
This commit also aims to reduce the gap between the accounting app and the transactions: account.payment objects are
created/validated upon completion of transaction.
To ease the capture/voiding of pending transactions, the related buttons are now displayed directly on the SO/invoice
instead of the transactions.
Was task: https://www.odoo.com/web#id=35857&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #24043
[FIX] add domain based on journal to payment tokens
Was opw: https://www.odoo.com/web?debug#id=1828206&view_type=form&model=project.task&menu_id=5200
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
Toufik Benjaa