If you open the shopping cart form in multiple tabs and complete checkout in one of them, submitting the open shopping cart form from another tab will reset the order status of the completed order to "Checkout: Checkout." The shopping cart form does not have equivalent checks to the checkout router's that prevent access to checkout pages for an order after the order has progressed beyond a break point in the checkout process (loosely defined as a page with no back form button).
We should add an alteration to the shopping cart form that checks the order status during the form build process, since that's the earliest we can get to it, to prevent shopping cart form submission when the shopping cart order ID no longer matches a user's current cart order ID or when the order status indicates the order has progressed beyond a break point. To prevent submission of the shopping cart form in these cases, we'll use a redirect to whatever the current page is.
Comment | File | Size | Author |
---|---|---|---|
#2 | prevent_shopping_cart-2410391-2.patch | 1.71 KB | mglaman |
Comments
Comment #1
rszrama CreditAttribution: rszrama commentedTagging for http://contribkanban.com/#/board/commerce/7.x-1.x.
Comment #2
mglamanI'm not sure why we'd check on build, since the form is built and we want to prevent the magic in commerce_cart_line_item_views_form_submit(). Attached is patch which reviews the order's state (more reliable than status.) If it's in cart or checkout state it can proceed. Obviously this assumes payment is the last step, which it technically has to be for Drupal Commerce. So should prevent issue.
Comment #3
jsacksick CreditAttribution: jsacksick at Centarro commentedFor some reason, I wasn't able to reproduce the bug this time (But I remember experiencing this on one of the project I was working on).
I believe this will occur if you have an Ajax cart form (otherwise the page is reloaded and you get the cart empty message since it's no longer your active cart)...
The patch looks good although I'm wondering if we shouldn't put some of that logic into a validate handler? In case we keep it this way, it'll silently fail...
Thoughts?
Comment #4
rszrama CreditAttribution: rszrama at Centarro commentedSame as Jonathan, I couldn't really reproduce this issue. I wonder if we resolved it elsewhere via form state fixes. In any event, the fix looks sufficient to me - a silent failure is fine since we're really just trying to prevent accidental (or intentional) subversion of a normal checkout flow. Committing as is.