Closed (fixed)
Project:
Ubercart Addresses
Version:
5.x-1.0
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
28 Aug 2008 at 18:32 UTC
Updated:
29 Sep 2008 at 02:41 UTC
situation:
user fills the address fields, but forget at least one required one, user clicks on preview order and receive error, user enters the require field and press preview order.
bug:
now user has duplicate addresses and the incomplete address is the default.
Comments
Comment #1
freixas commentedI changed the issue title to something more accurate. The addresses are not duplicates. They are similar, with one version lacking a required field.
Comment #2
freixas commentedFixed. Thanks for catching this as it led me to catch a few more things.
Could you please get the latest code from CVS (or wait until the dev build is updated) and let me know if I've fixed your problem without introducing any new ones?
Thanks!
Comment #3
ginc commentedthanks for the quick response. i'll check it out within next days and let you know
Comment #4
ginc commentedi finally found time to play around with this module but can't quickly figure out the changes you made to fix the bug, can you please tell me the cvs version of the commit? or even better submit a patch?
Comment #5
freixas commentedI used the wonderful TortoiseCVS program and WinMerge to look at that version 1.1.2.3 of uc_addresses.module and the previous version and help me remember what I did. I believe the fix for the problem you reported was a one line fix. From:
to
The idea is I now check for the addresses only when a payment is received. This is the best clue I have that the order has been placed and finalized. Before, I would try to save the addresses every time the order was saved, which occurred when you moved from the checkout page to the review order page. If you moved back to the checkout page, I would save the addresses again, correct or incorrect.
I would recommend upgrading to the 2.0-rc1 release as it has a lot of other important bug fixes.
Comment #6
ginc commentedwhat if the payment method is COD (cash on delivery)? maybe it's better to save them after review order page when user submits the order???
Comment #7
freixas commentedI have to re-check, but I believe that there is no special signal that I would get at that point. The order is actually saved when you go from the checkout page to the review page. If the payment is COD, I'm not sure I will get a signal when the user submits the COD order. I'll have to try it to be sure.
Comment #8
ginc commentedI think we have another option to fix this bug:
when user goes from the checkout page to the review page, before saving, check
if the new address is identical with at least one of saved addresses && have new fields that aren't in the saved address
(maybe it's better to say it this way: if any of saved addresses have identical filled fields with the new address)
if true update the old saved address on db instead of saving a new address.
I saw a function "_uc_addresses_db_check_address" in your module that check for duplicates, i think a little modification will make it capable of doing this job as well
this solution will always work as if user fill a new field in existing address,he never wants it to be saved as a different address. e.g. adds postal code to existing address
Comment #9
freixas commentedI don't think your proposal will work.
I thought about the database query and I think that it would be possible to write one that does what you are asking. But you could get back more than one match. Which one would get updated?
The reason you could get back more than one match is that when a user manually adds a new address (through My Account), I am not going to second-guess them and turn the add into an update. The algorithm you propose would, at most, be applied to automatic address saving during checkout.
Also, consider this: I go to checkout and enter the wrong street address. Then I click on Review Order. I see the wrong address and go back to correct it. I click on Review Order again. Now there are two addresses added, one of which is incorrect and I still have the bug you filed.
Let me know if I my reasoning makes sense to you.
Comment #10
freixas commentedOk, after some study and testing with COD and credit card orders, I came up with this:
I'm not sure how I missed the 'submit' state before, but together with 'in_checkout', it seems to capture the data after pressing the Submit button to finalize the checkout order (seems so obvious now).
The code is checked in to CVS and should show up in the dev build in a day or so.
Thanks for thinking about this. If you see any other problems, let me know!
Comment #11
ginc commentedu are right, i'll test the code and let u know
Comment #12
freixas commentedComment #13
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.