Jump to:
| Project: | Ubercart |
| Version: | 7.x-3.x-dev |
| Component: | Cart/checkout |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
When a customer has previously placed orders, there will be drop down called "Saved addresses" from which the customer can select an address.
At first, when selecting an address for delivery no shipping costs are calculated. But when selecting an other address, shipping costs *are* calculated, but these shipping costs are based on the previously selected address.
Example
Let's say whe have three flat rates:
1. $ 5.00 (valid when postal code is "11111")
2. $ 7.50 (valid when postal code is "22222")
3. $ 2.50 (valid when zone is "Alabama" (= 1))
The customer has placed three orders in the past, one with postal code = "11111", one with postal code = "22222" and one with zone = "Alabama".
The customer wants to checkout for the fourth time, he/she adds a product to the cart and goes to the checkout page.
At first, the customer selects the address with postal code 11111 from the saved address drop down. No shipping costs are calculated.
Second, the customer changes his/her mind and selects the address with postal code 22222 from the saved addresses drop down. Shipping costs are calculated and result into $ 5.00. This is wrong, because that rate may only be valid when the postal code is "11111" and the current postal code is "22222". So the shipping costs should have been $ 7.50.
Modules installed
- uc_cart
- uc_order
- uc_product
- uc_store
- uc_quote
- uc_flatrate
- rules
- rules_admin
(and modules were the above listed depend on)
Attachments
I have the following files attached:
- A file with the rules I had defined.
- A PHP file, to be executed in a Drupal environment, that adds three orders and three flat rates to the database. With this you can faster setup a test environment to reproduce the bug.
Images
Also attached are some images to clarify what's going wrong.
1. Customer enters checkout page. No shipping costs are calculated.
2. Customer selects address with postal code = "11111". No shipping costs are calculated.
3. Customer selects address with postal code = "22222". Shipping costs for postal code = "11111" are calculated.
4. Customer selects address with zone = "Alabama". Shipping costs for postal code = "22222" are calculated.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| rules.txt | 1015 bytes | Ignored: Check issue status. | None | None |
| db.php_.txt | 2.21 KB | Ignored: Check issue status. | None | None |
| 1-checkout-page.png | 76.72 KB | Ignored: Check issue status. | None | None |
| 2-select-pc-11111.png | 79.61 KB | Ignored: Check issue status. | None | None |
| 3-select-pc-22222.png | 83.02 KB | Ignored: Check issue status. | None | None |
| 4-select-zone-alabama.png | 85.12 KB | Ignored: Check issue status. | None | None |
Comments
#1
Is this still an issue with all the Ajax checkout changes that have gone into 7.x-3.x-dev?
#2
Not sure. I hope to find time to test this scenario soon.
Guess I forgot to mention in this issue this was a follow-up of #1448288: Shipping costs not triggered correctly on /cart and /cart/checkout. (See #23 and #24 of that issue).
#3
Yes, this is still an issue. I've retested the scenario posted in #0 with a clean install and Ubercart 7.x-3.2+72-dev. I executed the attached PHP-file in #0 to recreate the shipping rates. Then I imported the rules attached in #0 one by one. And finally I cleared all caches. As that somehow resulted in the rules to be reverted, I re-saved each shipping rate, imported the rules, re-saved the rules and cleared all caches again. This time the rules stayed in place.
Shipping quotes keeps being one step too late with calculating shipping costs; it calculates the costs for the situation that was valid before an other address got selected. I tried adjusting the ajax settings at admin/store/settings/checkout/ajax, but I saw that "Delivery: Saved addresses" was already set to update the shipping quotes pane.
#4
I have a similar problem. When I change Country - shipping quotes calculates for a previously selected value.
I traced ajax call and found that the problem is in weight sorting at the end of _uc_checkout_pane_list().
In my situation quotes pane should be placed before delivery information pane, but shipping quotes can be properly calculated only if it's placed AFTER delivery address pane. I think there should be predefined panes processing priority, otherwise moving panes can cause errors like this.
#5
@FATALIST
Are you sure that shipping costs are calculated correctly when the quotes pane is placed after the delivery pane? When I tried to reproduce this bug the last time, I did had the quotes pane after the delivery pane. So I'm not sure if the root of this problem lies with the order (sequence) of the panes. It could also be a race condition as in #1454080: Shipping calculation not work if choosing existing address (Drupal 6 versions of Ubercart Addresses).
#6
@MegaChriz
Yes. I tested both of combinations and I seen code.
In _uc_checkout_pane_list() Ubercart gets list of panes and sort it by weight. Next, in uc_cart_checkout_form() ubercart iterates over all panes and calls 'prepare' callback for each one. In calls chain script calls uc_quote_action_get_quote() and finally it calls quote callback (line 103 in uc_quote.pages.inc). In my case it been uc_global_quote_quote. Problem is that $details contains old delivery country (because delivery pane not processed yet) and callback return quote cost for old country. This is totally explains why quotes keeps being one step too late from delivery counrty dropdown value.
#7
Update:
Problem is in callbacks sequence:
on ajax callback I get this sequence:
Problem is that quotes calculating on uc_cart_checkout_pane_quotes (process), but address fields updating in uc_cart_checkout_pane_address (process). It affects quotes that depends on delivery address (uc_global_quote in my case).
#8
The 6.x-2.x equivalent of this issue was #1084086: Invalid option selected. Recalculate shipping quotes to continue., closed that as a duplicate.
#9
I'm not sure, longwave, if the other issue is exactly a duplicate. I had this issue also with the quotes pane placed after the delivery pane, but starting with at least three shipping rates. Maybe we talk about two different issues here, though with the same error results.
I'd like to write a test for this case, but I think it's quite hard (or maybe even not possible?) to do, because, as far as I know, you can't execute javascript during automated tests. I recently found out that it's possible to simulate an AJAX call in tests, but I think that will not be accurate enough for this issue.
#10
I had a similar issue due to pane position/weight: see this post.