Define custom requirements for an order

[martijnvdbrug]

Is your feature request related to a problem? Please describe.
I would like to set the requirements needed for an order.

Example: I sell e-books, so I don't need a customer's shipping address to fulfill an order. However, some components like addPaymentToOrder depend on the restriction that an order has a shipping address.

Describe the solution you'd like
It would be nice to be able to implement a requirementsMet(order): boolean strategy or handler, so that I can tell Vendure that my order only needs a customer's email address.

🎰 BONUS: I would like to be able to select requirements on a per Channel basis via the Admin UI.

Example:In channel 1, If order contains only 'e-book' and no other products, then no address is required. If order contains 'e-book' + physical product, then the requirements are needed. (< This feels like it should be part of fulfillment or shipping?)
However, channel 2 would like to use a different requirementChecker, because that channel would also like to have a customer's name for emailing purposes.
⬆️ Just initial thoughts

Describe alternatives you've considered
For the e-book use case I can set a dummy address, but this is really a workaround.

Additional context
Slack thread

[ashitikov]

I think this mechanism should be a part of shipping method, because e-books should also be shipped, but remotely to email address without any physical address. You correctly pointed in your issue, that there may be a cases where cart includes physical products as well as virtual. This makes me think that graphql method eligibleShippingMethods should be called before physical address set. Even if shipping method can not calculate delivery price without address, this shipping method should be returned by eligibleShippingMethods with additional info, why it's not calculated. Storefront should use such additional information to honor shipping method requirements.

In your case you will have two shipping methods: delivery and email.
Case 1: e-book + physical. Storefront call eligibleShippingMethods. Delivery calculator returns some kind of structure { result: false, reason: { requires: ['address'] } }. Email calculator returns { result: false, reason: { message: 'Physical products can not be delivered by email shipping method' } }. Storefront see that only 'Delivery' is eligible, but it requires address, so it proceed user to address selection step.

Case 2: e-book only. Storefront call eligibleShippingMethods. Delivery calculator returns { result: false, reason: { message: 'No items to deliver' } }. Email calculator returns { result: 0 }, which means zero cost. Storefront choose email as shipping method. No address required.
Case 3: physical only. The same behavior as in case 1.

Once address is set, storefront uses eligibleShippingMethods again to make sure shipping method is available.

The main idea is to use shipping method as a key-point to understand how an order can be delivered. This is high-extensible mechanism. It is possible to introduce additional workflow-method on calculator or eligibility checker to exclude breaking changes.

In my case, I have two shipping methods: self-service (pickup) and classical courier delivery. In case of self-service we do not need to ask user for address, so first of all storefront show shipping methods, then if address required storefront ask user address.

[Domino9697]

Another use case to consider here: Custom requirements for order operations

Right now, calling the setOrderShippingMethod fails when the order is not in AddingItems state which could be problematic when defining a custom order process.

In my use case, I defined a cutom order process to have greater stock control. I added a EnteringShippingAddress and a EnteringShippingMethod order state. Whenever the user transitions to the first, I allocate some stock based on the order. But when I arrive on the EnteringShippingMethod state, I am blocked because I cannot call the setShipping mutation on the specific order state.

This AddingItems state verification is not limited to setOrderShippingMethod. I see in the code that we also make these verifications when adding items and removing items which could be problematic with a custom checkout process.

[ashitikov]

The same thing may be applied to payment method: in some cases user may want to know why user is not allowed to pay with some payment method. This can be implemented by returning a string from eligibility checker. But in case if developer want to return more complex thing, like array of conditions to be met to be able to use this payment method, I think, we should change signature of eligibility checker for shipping and payments.

[martijnvdbrug]

@ashitikov and @Domino9697 I am closing this issue, because it's a bit too generic: Some of these use cases can be solved with configureDefaultOrderProcess and others can be solved with just a custom order process or one of the configurable strategies

I suggest opening new issues for your specific use case, if you are still having issues with this.