website_sale_delivery checks whether delivery_type is set to 'fixed' for some behaviours. And before this commit, multi-destination carriers effectively always had the delivery_type set to 'fixed'. However, because children of the multi-destination carrier can be something other than 'fixed', this causes some strange behaviours.
(Example, on the delivery selection page, you expect 'Select to compute delivery rate' to show up for non-'fixed' carriers, but this doesn't happen.)
We can't make website_sale_delivery aware of destination_type, but we can introduce a non-'fixed' delivery type. So that's what we do here.
The choice was made to turn the destination type into a computed value dependent on the delivery type because there is strong coupling between the two values, and trying to keep the two values in sync using onchange/constrains/etc resulted in terrible spaghetti code.
Re-opened because this was stale in #677, #540
website_sale_delivery checks whether delivery_type is set to 'fixed' for some behaviours. And before this commit, multi-destination carriers effectively always had the delivery_type set to 'fixed'. However, because children of the multi-destination carrier can be something other than 'fixed', this causes some strange behaviours.
(Example, on the delivery selection page, you expect 'Select to compute delivery rate' to show up for non-'fixed' carriers, but this doesn't happen.)
We can't make website_sale_delivery aware of destination_type, but we can introduce a non-'fixed' delivery type. So that's what we do here.
The choice was made to turn the destination type into a computed value dependent on the delivery type because there is strong coupling between the two values, and trying to keep the two values in sync using onchange/constrains/etc resulted in terrible spaghetti code.