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.

Comments

bpirkle created an issue. See original summary.

amateescu’s picture

That 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?

bpirkle’s picture

That 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.

bpirkle’s picture

Patch attached

amateescu’s picture

Status: Active » Fixed
StatusFileSize
new5.14 KB
new2.05 KB

Thanks for the patch, it looks very good! I did a few small cleanups (the interdiff attached) and committed it to 7.x-1.x.

  • amateescu committed f15fbee on 7.x-1.x authored by bpirkle
    Issue #2577617 by bpirkle, amateescu: Status change instead of deletion?
    

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Damn-Deal-Done’s picture

This 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

avpaderno’s picture

@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.