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

joachim created an issue. See original summary.

swickham’s picture

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

joachim’s picture

Yup, 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.

shabana.navas’s picture

Joachim, 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.

joachim’s picture

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

bojanz’s picture

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

joachim’s picture

I'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!

drupgirl’s picture

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

joachim’s picture

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

drupgirl’s picture

Status: Active » Closed (outdated)

Okay, 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.