[Checkout] Customers can checkout with non-matching shipping and product categories

[audez]

Description

Users shouldn’t be able to checkout if they select a shipping category that doesn’t match a product's "shipping category".

It is said in the user guide “ if you sell products listed with a shipping category of 'frozen' then in order for the customer to be able to successfully checkout their shopping, the 'frozen' category will need to be checked in their desired shipping method.”

Expected Behavior

If the cart contains at least one product that doesn't match with the shipping method category, the shipping method should be disabled/greyed out, with an explicit message to the user, for instance:
"This shipping method is not allowed for some of the products in your cart, due to temperature requirements.”

Edit from Rachel: ☝️ This solution would be ideal if we could point the user to the products that can't be shipped. It needs to be designed as we don't have these type of message in the styleguide yet. To fix the s2 in the meantime, the expected behavior can be to not display the shipping method (like we do in case of tagging).

Actual Behaviour

User can checkout anyway. It has been mentioned here too.

Steps to Reproduce

1. Connect as admin to a shop that has an ongoing OC
2. Edit one product (admin/products/XXX/edit) to set a specific "shipping category" (for ex "frozen")
3. In the Shipping method settings (admin/shipping_methods/XXX/edit), select another category
4. Try to checkout with this product and this shipping method
5. See that it works

Animated Gif/Screenshot

I created an OC with one product having the "Produits refrigérés" category

I set the shipping method to another category

I can checkout

Workaround

?

Severity

bug-s3: a feature is broken but there is a workaround

[RachL]

@audez have you testing on legacy checkout or new checkout?

[audez]

just tested on split checkout and the bug is here too :/ I added screenshots :)

[amidaOFN]

hi team, Ronella has just upgraded this bug to s2 as we could not find a workaround.

We have a hub user who needs to be able to use shipping categories to designate product shipping requirements, so this is quite a barrier for them

[lin-d-hop]

I would deeply encourage us to fix this on split checkout and focus on the split checkout roll out if we possibly can.
@RachL shall we (have we?) stop fixing bugs on old checkout unless they are s1s? Controversial but I'm so keen to get the slpit checkout roll out done ;)

[RachL]

Yes perhaps we haven't advertise this enough, but when we started the 1rst split checkout roll-out, we already decided to not fix legacy checkout anymore. So for release testing for example, we only test split checkout.

We need to communicate this again, yes 👍 So here this change needs to be done on split checkout only.

[kirstenalarsen]

So can we agree that we're only fixing this on split checkout AND it is an S2 and therefore it should be fixed? OR are we rolling out split checkout first? I would vote for the former so that we can roll it out with this nice fix as a value-add

[RachL]

@kirstenalarsen

AND it is an S2 and therefore it should be fixed

It's already an s2. The team didn't have the time until now because we had other s1 and s2 (that targeted way more users) to deal with.

OR are we rolling out split checkout first? I would vote for the former so that we can roll it out with this nice fix as a value-add

I don't see the link with the roll-out? This bug exist in legacy checkout as well. It shouldn't block the roll-out. It becomes really urgent to start the roll-out, let's not add old existing bugs as roll-out blockers?