I'd like to set the UPS Ground Shipping Method to default checked when the rate is showing in the checkout pane (based on some rule sets I've configured, sometimes it will not display.) I have two possible shipping rates, UPS, and Customer Pick Up (which is a flat rate of 0). I assume this means that any time the UPS rate is queried, it will be necessary to set UPS Ground Rate to checked (even if this user had previously selected Customer pick-up after generating UPS Ground rate.) This is okay with me.

The issue is that when I set the list position for UPS as the "first" method, the flat rate option still defaults to checked instead of UPS.

Steps:

Go to admin/store/settings/quotes/methods, set the List position
Set UPS to a lower value than Flat Rate (e.g. UPS as 0, Flat Rate set to 2.)

When UPS gets queried in the order check-out pane, Customer Pick-Up is still the default checked option. When UPS appears, flat rate is shown to be below UPS.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

longwave’s picture

Status: Active » Fixed

There have been some changes to the way the shipping quote pane works recently, please retest with latest -dev and reopen if this is still an issue.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

TR’s picture

Status: Closed (fixed) » Active

I've confirmed that this issue still exists in the current -dev.

To reproduce, set up two flat rates, call them "First" and "Second" for clarity. We want "First" to be the default method selected - if the customer wants "Second", the customer should have to explicitly select "Second" at checkout. So make sure "First" is at the top of the table at admin/store/settings/quotes/methods.

Now here's the key to reproducing the failure: Set up a condition for "First" that depends on something the user has to type in on the checkout page, e.g. destination country.

When the customer first visits the checkout page, "Second" is initially the only available quote because the customer hasn't entered the information necessary to satisfy the condition. The "Second" method will automatically show up in the shipping quotes pane, and because it's the only available shipping quote it will be selected (checked) by default.

Enter delivery and billing address, making sure you satisfy the condition you set up for "First". "Second" is still the only method that shows up - you have to click the "recalculate" button to get "First" to show up. That's a bug, but it's the subject of a different issue, so just ignore that bad behaviour here. Once you recalculate, "First" and "Second" will now both show up. "First" will show up first in the list as expected, but "Second" will be selected by default, which is not what we want. This is because "Second" was already selected and re-submitting the form via Ajax preserves that selection.

The end result is that "Second" is always chosen for the customer by default, so shipping will default to "Second" unless the customer explicitly chooses "First". This is the exact opposite of what we want.

This affects not only flatrate with conditions, but *any* shipping method that requires a calculation based on some information entered by the customer at checkout. Thus, USPS, UPS, FedEx, Canada Post, etc. can never be set as the default selection if there is any non-computed method (flatrate or weightquote, without conditions) configured.

wodenx’s picture

Status: Active » Needs review
FileSize
1.72 KB

We need to distinguish between a quote that is explicitly chosen and one that is selected by default. We also need to persist that information accross multiple reloads of the checkout page, or the quote will always revert to the default. I debated between saving this in $order->data and adding a column to {uc_order_quotes}, and decided the former was (very slightly) less ugly...

Status: Needs review » Needs work

The last submitted patch, 1215636-quote-default.patch, failed testing.

wodenx’s picture

Status: Needs work » Needs review
FileSize
2.21 KB

Thank you bot.

TR’s picture

Status: Needs review » Reviewed & tested by the community

I've been using the patch for about 5 days now. It fixes the problem.

longwave’s picture

Status: Reviewed & tested by the community » Fixed

Committed #6.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.