After an order is submitted and the user doesn't get the new address saved.

Please review bug #301233: Invalid address saved. You will see that originally, I checked for the 'save' state. This causes a problem if the customer spots an error in the address (in the review order page) and goes back to fix it. The wrong address is saved and then the fixed address is saved,

Please provide a more detailed description of your problem. What payment system are you using?

Also, read bug #301233: Invalid address saved and verify that your patch has not re-introduced the problems discussed there. Thanks!

I am having the same issue. Address info in uc_orders looks fine. Order was paid for using PayPal standard. After order payment the uc_addresses and uc_addresses_defaults tables contain no records matching the uid of the order.

The uc_addresses module works fine if the user maintains / adds an address before adding an order. but seems to fail if the user has not added an address prior to entering the order.

In testing, it worked fine with check payments. I only allow check & PayPal Standard payments.

We require that addresses be entered to manually add an account, however we imported user & profile information using the User Import module for start-up. Imported users do not have an address record as there is no way that I can find to import address records.

Here is the code beginning at line 513, as discussed in #301233. It has not been modified.
==========
function uc_addresses_order($op, &$arg1, $arg2)
{
global $user;
$order = $arg1;

if ($op == 'submit' && $order->order_status == 'in_checkout') {
$address = new stdClass();

// Add the billing address first. If the user has no addresses,
// this is the one that will become the default address
=============

I'm using the following build:
; Information added by drupal.org packaging script on 2008-12-29
version = "5.x-2.1"
project = "uc_addresses"
datestamp = "1230593131"

Hi,

I checked my test system and it uses PayPal Website Payments Pro, so I haven't tested with PayPal Standard.

I still believe the patch will create the problem described in bug #301233: Invalid address saved, so that's not a good solution.

If anyone with PayPal Standard could record the values of $op and $order->order_status during a PayPal Standard transaction, I might be able to help fix this. The idea would be to add this code right before the "if ($op == 'submit' && $order->order_status == 'in_checkout') {" line:

file_put_contents('some filename', "op = $op order->order_status = {$order->order_status}");

Then place an order and follow it through to a successful completion. It might be useful to also place an order and then cancel it, to see how that differs. After performing the transaction, the file whose name you selected will contain the results.

For the successful completion:

For a canceled order:

The operation 'save' is called BEFORE the PayPal payment is made. It would seem that either 'can_update' or 'update' would be the flags to use when trying to gather information.

Is there other information I could help gather with this?

Bryan O'Shea

Looking through the code in uc_paypal, uc_addresses, and uc_cart.module, I think I figured out what the issue is.

uc_cart.module, line 1693, issues a module_invoke() to uc_addresses, along with any other module that implements hook_order (one at a time, with a foreach loop). However, this is never fired in the case of PayPal web payments standard, because the form uc_cart_checkout_review_form is not used; uc_paypal_wps_form is. I don't know about web payments pro, as I haven't looked through all that code.

The solution, I would propose, would be to use either op=can_update or op=update to set the user's addresses, since WPS doesn't ever see op=submit. Would this prevent the problems in #301233: Invalid address saved, and solve the problem here to everyone's liking? I've attached a patch for op=update, in the hopes that it helps to fix the problem for everyone.

Bryan O'Shea

Bryan,

Thanks so much for the time you've spent on this.

I am reluctant to install your patch without testing it with other payment systems and I don't have the time to invest in the testing right now. You would probably be reluctant, too—you need to enable a variety of payment systems and track the various states that the order passes through to ensure that the address is always saved once but never saved twice. It's a tough job and needs to be repeated for the D6 version.

If someone would volunteer to go through this exercise and could print out debug statements for the major payment systems that show that the address is saved only once when the patch is installed, I would be more willing to apply the patch,

The alternative would be to create a patch that checks that the current payment was made using PayPal Standard and then adjusts the code accordingly. Keep in mind that many people have more than one payment system, so you need to find out which payment system was used for the current order, not just whether someone has PayPal Standard. If the change was restricted to PayPal standard payments, it would be far safer to implement.

If someone creates such a patch, it should be tested on a system with at least two payment systems enabled and some debug tracing or other evidence should be presented to show that the addresses are saved correctly for payments made using either payment system.