If using Stripe we did "Pay Now" -> close modal -> "Pay Now" we would
get 2 modals and possibly be blocked by infinite loading.
With this changeset, we only execute one time our strip.js file so we do
not declare multiple MutationObserver.
We also only open one checkout at a time from stripe when closing and
opening it or multiclicking click (the later one that could block the
interface with several stripe iframe opened and one with a infinite
loading wheel).
opw-1939323
closes#31928
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Create an order from the eCommerce
- Choose to pay with Stripe
- Enter the credit card info, validate
There is a short window of time (before the reload of the page) where
the user can click on 'Pay Now' again.
This is because the HTML is completely replaced, including the button.
We restore it when necessary.
opw-1866332
In a previous commit, we removed the use of the 'btn-sm' classes as we
used it everywhere for default-size buttons instead of customizing the
size of those default-size buttons directly.
This commit proves it was even more necessary as the 'btn-xs' class does
not exist anymore in BS4 and we so can use the 'btn-sm' class instead.
Before this commit, when paying a confirmed SO with the token access with Stripe,
Clicking on the button "pay now" wouldn't do anything, because the id of the SO couldn't be retrieved
After this commit, the regex that does just that is more generic and the flow works
OPW 1881192
closes#26884
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
- Stripe.js was limited to only a few pages, which means, if you tried to
implement a new payment route it would never work without modifying
stripe.js to support the new case.
This commit allows stripe.js to be generic and work with any page.
Purpose
=======
Currently, users have to retype email in the stripe payment popup.
For event registration, the email address must be typed 3 times (the first
for the registration information, the second for the billing information
and finally for the payment on the stripe popup)
Specifications
==============
As the email is already filled on billing information view, isn't
necessary to retype in the payment form.
- 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.
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.
Before this commit:
On portal (My Account > Invoices > Pay Now), a stripe payment in a normal
currency (eg: a non integer currency) would debit the amount *100.
This comes from b335ae0348 which added a workflow to handle integer
currencies but it also sent the *100 amount to /website_payment/transaction
that would create a TX with that amount instead of the normal amount.
Now, the normal amount is correctly sent to the backend, the multiplied amount
is just sent to StripeCheckout handler to correctly display the amount on the
popup after clicking on "Pay Now".
Note: the amount will be multiplied on the backend independently ecda057e11
In case an invoice is required to be paid thanks to the route
'/my/invoices/', the user is redirected to '/shop/payment/transaction/'.
If website_sale is not installed, this causes a crash.
Complement of 2bd17285ea
opw-813481
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
This commit b335ae0348 previously sent currency instead of currency_id on
/website_payment/transaction route resulting in a cast error.
Now, we send the currency_id as the route expect
This closes#19468, closes#22165
- Before this patch, stripe doesn't get displayed.
It was a bug related to the fact that stripe doesn't respect how the generic payment form works.
So to make it work, we were relying on small hacks that got broke by changes on the payment form.
To fix the bug we are no longer adding an event to the pay button of the payment form, instead
we listen all the changes made to the DOM and detect if a form with an attribute 'provider' set to
'stripe' is added.
If so, we open up the Stripe payment form.
- Fix ACL issue when trying to pay with Stripe on eCommerce without being logged.
Closes#20202
opw-776200
- There was no feedback to the user when executing the Charge
transaction in server-to-server mode, while it could take several
seconds, with the normal UI/action buttons still available.
- Stripe integration was almost working along with `website_quote`
payment, but entirely broken with `website_payment`, and partially
broken with `website_sale`.
Fixing it required:
+ More leniency in processing optional transaction parameters, which
may or may not be present in the various payment flows.
+ It also required more precautions when locating the transaction for
which the Stripe Charge was to be created, which passed in different
manners in the session. The route now supports an explicit `tx_id`
to allow forcing the transaction without risk of mixing different
payment flows.
+ FIXME: There is still some amount of duplication and bad modularity
in the handling of the various payment flows in relation with
Stripe.
- We provided very little metadata to the Customer and Charge APIs of
Stripe. We now pass more names and references to make Stripe payments
easier to manage in the Stripe dashboard.
- In some cases, selecting Stripe as payment method caused a second
inclusion of `stripe.js`, raising a JS error because of the
duplication.
- Strip whitespace in emails: the Stripe API raises an error for
transactions done with invalid emails, including with
leading/trailing whitespace.
Customers will have a hard time figuring out the problem
by themselves, so we should at least strip whitespaces.
To reproduce:
- Buy a product costing 0.01
- Validate the cart, pay with Stripe
- Enter the credit card info, validate
Stripe cannot process the transaction (minimum charge is not met), but
the user is not warned about it. The Stripe pop-up is closed and the
error is recorded in the console silently.
opw-765775
JS code managing transaction creation through acquirer 'Pay Now' form
button is improved in order to be less website-sale dependant. It now
takes parameters for access token and URL to call in Json. Class used
to bind JS is now o_payment_acquirer_button in order to be more generic.
eCommerce module is updated accordingly. Future commits will probably
make Online Quote (website_quote) use it.
Access token field is moved directly in sale module. Indeed future commits
will improve customer portal and access tokens will be used in other module
than website_quote. This commit already moves the field.
Moreover some strange code in website_sale already uses access_token even
if it does not exist in that module. Moving the field solves that issue.
Finally so_token defined in stripe is renamed to access_token to have the
same naming through all addons.
The module `payment_stripe` was apparently not designed to work with
module `website_payment`, althought the payment method is available. For
example:
- Go to '/my/home', select "Pay Now" on an invoice
- Try to pay with Stripe ==> nothing happens
This commit brings the necessary modifications to make it compatible
with `website_payment`. Moreover, it prevents the creation of 2
`payment.transactions`, which was not necessary.
opw-693421
Christophe Simonis