Order managers should be able to set an order or multiple orders to a specific status

[spencern]

Users with permission to view and process orders should be able to update the status of multiple orders in bulk.

If any orders are selected and bulk set to a state that is not the next status in the order flow, there should be a confirmation such as:

You've requested that 17 orders be set to the "Shipped" status, but 4 of these orders are not in the "Packed" state and would skip all steps leading up to the "Shipped" state. Are you sure you want to do this?
[Yes, Set All Selected Orders] [No, Cancel] [Set All Packed Orders]

While setting the state of the selected orders, the orders should have an event added to their history showing that they have been set into a specific state by a bulk operation.

See: #2325 for how to select orders for bulk processing.

[rymorgan]

Links for designs below

Reaction core team link:
https://zpl.io/Z1MCuWh

Public link:
https://scene.zeplin.io/project/58af8900737c137280322bd6/screen/58faa0e175ba8a9495284660

[kieha]

Notes:

• Track progress on branch kieha-bulk-order-status-2341

Updates:

• Implemented list that shows up on Bulk Actions click
• Have most of the designs for the list above implemented

[kieha]

Updates:

• Have part of the functionality for setting the status of an order implemented.
• I realized that the statuses of picked and labeled don't currently exist. Working on creating backend methods for them.

[kieha]

Updates:

• Implemented functionality for multiple orders being set to a specific status.

Just a couple of questions on this ticket @spencern:

1. Should we allow people to regress statuses? I.e. if I ignore the flow and set an order's status to Shipped, meaning Picked, Packed and Labeled statuses have been skipped, should I be allowed to go back and set it to Picked if I wished to?

[spencern]

Hi @kieha

Yes, I think it's important that people can regress order status, even to status that we're not skipped. Perhaps this is something that could be an admin setting (canRegressStatus or similar) but we need the functionality.

Curious what @aaronjudd thinks on this, but it's something I've built before and was highly requested feature at GetOutfitted until we built it.

Sometime's users accidentally click a button or in a bulk action select the wrong order. They need to be able to undo it.

As with every order related action, it should be logged, including the user who performed the action, but I do think that we need this functionality.

[kieha]

Updates:

• Putting back WIP label on PR [Marketplace] Set order(s) to a specific status #2613 to rethink/redefine shipping workflow implementation using the Workflow object

[brent-hoover]

Not to be a bummer but is there a reason that I can't "Approve" orders in bulk?

[rymorgan]

@zenweasel I was discussing this with @spencern and unless the approval step is a requirement for some payment provider then I think we should remove that step entirely. The payment and fulfillment flows should be as streamlined as possible. Since people will have to do these steps over and over. Do we need that step at all?

[brent-hoover]

I'm not the defender of the Approve step 😄 , it's just always been here. But if we all agree there's no point to it, let's get rid of it for sure. I just wish I knew why it was there in the first place.

[rymorgan]

The idea is that you would do bulk capture here -- and bulk fulfillment with the drop down. Which reflects the overall flow that happens in the sidebar with one order.

[kieha]

@spencern in regards to the Approve then Capture flow of payment in an order, I need some clarification. Since this is the flow followed on an individual order (on the side bar), should it not also be the flow for bulk orders?

[spencern]

@kieha
Did our recent meeting help clear up this confusion?

[kieha]

Yeah, @spencern. Good to go on this.

[kieha]

Opened new issue #2724 for order shipping fulfillment flow re-implementation.

[spencern]

I'm going to close this as we've merged #2613

Follow #2724 if you're interested in seeing how this becomes more extensible