Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MIG][IMP] delivery_multi_destination: Introduce 'based on destination' delivery type #887

Open
wants to merge 1 commit into
base: 16.0
Choose a base branch
from

Conversation

carmenbianca
Copy link
Member

Backported from #871
Internal task T12787

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.

…livery type

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.

Co-Authored-By: Carmen Bianca BAKKER <[email protected]>
Signed-off-by: Carmen Bianca BAKKER <[email protected]>
@pedrobaeza pedrobaeza added this to the 16.0 milestone Sep 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants