What do you think about an option to change status on expired carts rather than delete them?
For one of GSATi's clients, a common workflow was that customers would build their orders over time, often moving them back and forth through checkout stages and modifying the order a few times before eventually completing the purchase. These tended to be larger orders, which we want to encourage.
However, an order in Checkout: Review already has many things assigned to it that could become stale. For example, this client changes shipping methods/costs fairly frequently, and an older order sitting in Checkout: Review may have a shipping line item stored on it that is no longer correct. Deleting older carts would solve the stale data issue, but would not have been received well by our client and their customers.
Our solution was to create a small module that pushes older orders back to Cart, so that the user can continue building their order but must reselect the checkout details: https://www.drupal.org/sandbox/bpirkle/2577473
This conceptually overlaps with Commerce Cart Expiration in some ways. Would you have any interest in adding a status change vs. order deletion option to Commerce Cart Expiration? If so, I'd be happy to work up a patch for you to review.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | interdiff.txt | 2.05 KB | amateescu |
| #5 | 2577617-5.patch | 5.14 KB | amateescu |
| #4 | commerce_cart_expiration-status_reset-2577617-4.patch | 5.1 KB | bpirkle |
Comments
Comment #2
amateescu commentedThat sounds useful indeed :)
It's been a while since I actually used the module myself so I had to look at the code again to see how this could be implemented, and my best suggestion so far is to create a new rule (+ an action and an event) that is similar to the existing one(s), and just have it disabled by default.
This way, site builders get the "delete" functionality by default but we provide a very easy way for them to switch to the "change status" functionality by disabling the default rule and enabling the other one.
What do you think?
Comment #3
bpirkle commentedThat sounds like a very reasonable approach to me. I will try to get a patch together in the next few days, unless someone beats me to it.
Comment #4
bpirkle commentedPatch attached
Comment #5
amateescu commentedThanks for the patch, it looks very good! I did a few small cleanups (the interdiff attached) and committed it to 7.x-1.x.
Comment #8
Damn-Deal-Done commentedThis is exactly what I want.
How do we know if we still need to add patches or know if the patches have been implemented into the main module?
Is there a way to tell this without doing hours of testing?
Thanks
Comment #9
avpaderno@Damn-Deal-Done The patch has been committed on November, 2015. The latest stable release has been created on September, 2016. It contains this patch too, if it hasn't been reverted after this issue was closed.