Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I've been creating test orders which use the 'fulfillment' workflow as part of my work on #2879263: License creation/destruction logic in sync with cart/order lifecycle.
However, my test orders remain at the fulfillment state.
What process makes them advance to complete? The only thing I can see to do that is to edit the order entity and set that manually, but that doesn't seem like good UX for store admins on a digital-only store.
Comments
Comment #2
swickham CreditAttribution: swickham at Acro Commerce commentedIf you go to the order's View screen you should see to buttons at the bottom of the summary data on the right: "Fulfill order" and "Cancel order". Once you click "Fulfill order" that will do the trick.
Comment #3
joachim CreditAttribution: joachim at Torchbox commentedYup, I can see there is a way for a store admin to do it manually.
But I can't find anything that moves it automatically, and that seems to me like something that ought to be there.
The manual operation makes sense for a store that sells physical products, such as a t-shirt. The workflow is:
1. customer completes order and pays for it
2. order is in fulfillment state
3. store admin looks at the list of orders to fulfill, or receives notification
4. store admin acts on the order: they put a t-shirt into a parcel and post it
5. store admin updates the order from the fulfillment state to the complete state
But for the case where the store sells digital products, such as a license, we have these steps:
1. customer completes order and pays for it
2. order is in fulfillment state
3. store admin looks at the list of orders to fulfill, or receives notification
4. store admin doesn't have to do anything at all, as the digital product has already been taken care of by the system
5. store admin updates the order from the fulfillment state to the complete state
Why is human intervention necessary here? It seems like a waste of the store admin's time, and not very good UX.
Comment #4
shabana.navas CreditAttribution: shabana.navas at Acro Commerce commentedJoachim, I believe this is where you have Order Workflow transitions. You have to find out which workflow the order follows (defined at the order type) and check out the transitions. Then, implement an event subscriber to subscribe to the transition you need. (See: http://docs.drupalcommerce.org/v2/orders/order-workflows-transitions.html)
So you can intervene using the event subscribers and you wouldn't need human intervention.
Comment #5
joachim CreditAttribution: joachim at Torchbox commentedHi Shabana!
Event subscribers reach to a change in state, which happens in the state field type when the order entity is saved (StateItem::preSave().
I guess as that's before the order is saved, an event subscriber could update the state, but we'd be changing the state within a state change, so the events for the new transition wouldn't get fired.
Also, how would our event subscriber know it's ok to do this, and that other event subscribers to the same event don't need something else?
Comment #6
bojanz CreditAttribution: bojanz commentedI agree that there are problematic moments here. We don't have a good way to skip a state automatically right now. That needs to be fixed in state_machine somehow.
Comment #7
joachim CreditAttribution: joachim as a volunteer commentedI've been pondering this and it seems to me that we need order *items* to have a state workflow too, one of:
- created -> complete
- created -> fulfillment -> complete
Then for a digital product, something like Commerce License marks the order item complete. For a physical product, a human store admin uses the form to mark that item as complete.
If some order items are in fulfillment, then the order itself can't be advanced to complete.
Once all order items are complete, the order is automatically advanced to complete.
We probably also need a 'failed' state, for a license that can't be granted, or a t-shirt that's found to be out of stock... but one thing at a time ;)
Though I'm really not sure if this is over-engineering things or not!
Comment #8
drupgirl CreditAttribution: drupgirl commentedOh wow. I guess I don't understand why the commerce license must be of order type fulfillment?
It seems to work just fine with the default workflow, and by fine I mean that the license is administered on purchase. Why is using the default workflow not the thing to do with licenses? What will go wrong if I use the default workflow to give out license roles? What does it matter?
Comment #9
joachim CreditAttribution: joachim as a volunteer commented> It seems to work just fine with the default workflow, and by fine I mean that the license is administered on purchase. Why is using the default workflow not the thing to do with licenses? What will go wrong if I use the default workflow to give out license roles? What does it matter?
I changed Commerce License to work with the default workflow after posting this issue.
Comment #10
drupgirl CreditAttribution: drupgirl commentedOkay, I thought so, as I read that other thread. I think the readme still says to use Fullfillment, but I'll mark this as closed outdated.
BTW, thank you, all, so much, the amount of work you've done is so helpful.