Add moveOrderItems mutation

[aldeed]

Part of #4999
Impact: minor
Type: feature

Changes

A new moveOrderItems mutation allows you to move one or more order items from one fulfillment group to another existing fulfillment group on the same order.

The operator UI does not yet implement this.

• moveOrderItems can be called internally to synchronize from an external system by setting context.isInternalCall to true
• moveOrderItems can be called through GraphQL by any user with "orders" permission for the shop that owns the order
• moveOrderItems can be called through GraphQL by the user who placed the order. In this case, the move will only succeed if both the item status and the order status are "new".

Breaking changes

None

Testing

1. Place an order.
2. Verify that the mutation works as described.
3. Verify that you can move order items when authenticated as a user with "orders" role or as the user who placed the order, but not when authenticated as someone else or when not authenticated.

[kieckhafer]

When I move an item between fulfillmentGroups, the itemIds array on each fulfillmentGroup is not updated, it keeps the original itemIds.

[kieckhafer]

Not sure if this is done on purpose or not, but I cannot move ALL items from one fulfillment group to another, and "close" the fulfillment group. I get an error You must specify at least 1 values, which doesn't completely make sense, but I believe based on not allowing me to move a single remaining item to another fulfillmentGroup, it means that each fulfillmentGroup must have at least one item in it.

[aldeed]

@kieckhafer I did intentionally want an error if you try to have no items in a group. It's something we could consider supporting in the future, but I think it leads to a lot of unanswered questions and potential confusion as far as what to do about group status, totals, etc.

I will fix the itemIds issue. Beyond that, I think there is a whole can of worms here that I hadn't realized until now. We probably need to recalculate totals after moving, or they won't make sense. The group totals will change, which means discounts, shipping, taxes, and surcharges could all change, too.

I think I'll need to pull out the placeOrder calculations to a util function, so we can redo them as the order changes. (The payments will then not necessarily match the total, but that can be handled by refunds or adding additional payments, something we'll add support for in a future PR.)

[aldeed]

@kieckhafer This should be ready for another look

[kieckhafer]

I'm having issues with what seems like Taxes not being calculated / added into the total, causing an mismatch error in total where I can't check out:

This mutation works when taxes aren't active, so it's possible this was something overlooked during my testing in #5027 when all those files were moved around, and not necessarily the fault of this PR.

[kieckhafer]

👍 good to go with updates