I'm going a site for a large company. Presumably there are multiple people working their warehouse, so there is not a single name that can be used for the pickup address field (it's a company, not an individual!). The default pickup address field lets you enter an address without the name fields, but then when you go to edit any product, you end up with a PDO exception. First, the form isn't being properly validated, and second why are those fields required in the database? That doesn't make sense to me. Third, why is it adding the default address every time I edit a product? What if I change the store address later? Then I'd have to go update a ton of products. The fail is strong in this one. ;-)

Comments

seanr’s picture

Here's the error:

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'first_name' cannot be null: INSERT INTO {uc_quote_product_locations} (nid, first_name, last_name, company, street1, street2, city, zone, postal_code, country, phone) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10); Array ( [:db_insert_placeholder_0] => 1973 [:db_insert_placeholder_1] => [:db_insert_placeholder_2] => [:db_insert_placeholder_3] => [:db_insert_placeholder_4] => [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => [:db_insert_placeholder_9] => [:db_insert_placeholder_10] => ) in uc_quote_node_update() (line 121 of /mnt/www/html/aaviddev/docroot/sites/all/modules/ubercart/shipping/uc_quote/uc_quote.module)
TR’s picture

Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)

I can't reproduce this error. My store default pickup address contains only the city, state, and zip code. I see no errors when editing a product or creating a new product. Perhaps you're using a much older version of -dev? There may have been problems like this six months ago or more in dev, when we were working on the new address code, but as I said I don't see this problem either in 7.x-3.0 for the current 7.x-3.x-dev.

seanr’s picture

Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Active

This is still very much an issue and it's breaking my site. I'm looking at your dev code and it's still doing exactly what's causing this. I have no idea how you're unable to reproduce it because the code does do it. ;-)

uc_quote_form_alter:

 196     // Use the store default if the product does not have an address set.
 197     if (empty($address)) {
 198       $address = variable_get('uc_quote_store_default_address', new UcAddress());
 199     }

uc_quote_node_update:

 106     if (!empty($node->shipping_address['street1'])) {
 107       db_merge('uc_quote_product_locations')
 108         ->key(array('nid' => $node->nid))
 109         ->fields(array(
 110           'first_name' => $node->shipping_address['first_name'],
 111           'last_name' => $node->shipping_address['last_name'],
 112           'company' => $node->shipping_address['company'],
 113           'street1' => $node->shipping_address['street1'],
 114           'street2' => $node->shipping_address['street2'],
 115           'city' => $node->shipping_address['city'],
 116           'zone' => $node->shipping_address['zone'],
 117           'postal_code' => $node->shipping_address['postal_code'],
 118           'country' => $node->shipping_address['country'],
 119           'phone' => $node->shipping_address['phone'],
 120         ))
 121         ->execute();
 122     }

uc_quote_install:

  42   $schema['uc_quote_product_locations'] = array(
  43     'description' => 'Stores default product origin addresses.',
  44     'fields' => array(
  45       'nid' => array(
  46         'description' => 'The {uc_products}.nid.',
  47         'type' => 'int',
  48         'unsigned' => TRUE,
  49         'not null' => TRUE,
  50         'default' => 0,
  51       ),
  52       'first_name' => array(
  53         'description' => 'The address first name.',
  54         'type' => 'varchar',
  55         'length' => 255,
  56         'not null' => TRUE,
  57         'default' => '',
  58       ),
  59       'last_name' => array(
  60         'description' => 'The address last name.',
  61         'type' => 'varchar',
  62         'length' => 255,
  63         'not null' => TRUE,
  64         'default' => '',
  65       ),

Those 'not null's, combine with your pre-populating the product address with the store default are causing PDO errors when the store default address doesn't have first and last name. This is critical as it is breaking the ability to update nodes on a live site (we get a fatal). At the very least, you need to allow null values for first and last name, but second, why are you pre-populating with the store default at all? That makes no sense - if the store default changes, now I've got to manually update several thousand product with the new address even though I never actually intended them to be anything other than the default? Why is uc_quote even doing that at all? It's beyond crazy to do that to me. If you've got a reason for doing that, I'd love to hear it.

Sorry for the bold, but that specific set of questions was never answered and as far as I am concerned is just as important as the fatal error due to the maintenance headaches that will cause down the road. That is completely unexpected and unwanted behavior.

seanr’s picture

Just figured out why you can't reproduce it - you've got no street address (uc_quote checks against that before the insert). Give yourself a company name and street address and watch the fatals begin. ;-)

TR’s picture

Priority: Critical » Normal

How about supplying a patch if you've go it all figured out?

"your dev code"
" your pre-populating"
"why are you"
"If you've got a reason for doing that"

To be very very clear - it is not *my* code, and *I* am not the one doing these things. This is a community project - it's *your* code. I and the other maintainers volunteer and donate thousands of hours of time to supporting and improving Ubercart. I responded to your initial bug report within hours by attempting to reproduce an error that no-one else has ever reported in the almost 5 years that Ubercart has been in existence. I made an attempt to reproduce your error based on the sketchy details you provided, and I spelled out exactly what I did so that someone else could try the same steps and so that you could point out any steps that I "missed" based on your incomplete bug report. I did not see the error you described; given that, your other questions were purely rhetorical. Lashing out at the only person who took the time to respond to your bug report is not a good strategy for accomplishing your goals.

If you would like to see this fixed, the first step is to provide a clear, detailed bug report listing specific steps that others can take to reproduce the error. If an error can't be reproduced, it can't be diagnosed or fixed. Indeed, the error may be due to some other module or some configuration you haven't mentioned. Then, try and contribute a patch, post it here, and let the automated testing and other community members test it to see if it fixes the issue and (more importantly) doesn't cause any new issues. Or you can wait until someone sees the issue and volunteers to devote time to fix it. Again to be clear, no one is obligated to fix anything for you, or even to read your issue. This is all done on a volunteer or need basis. As in, if I need it, I might work on it. Likewise, for any other community member, including you.

Please read the link below describing issue Priority values. Critical to you does not equal critical to this project. If it's that critical to you then you should be willing to spend the time or the money to investigate and fix the problem and contribute your fix back to the community that has already contributed the entire Drupal and Ubercart package to you. Given the length and depth of your involvement with Drupal I would have thought you would know all this already.

TR’s picture

Issue summary: View changes
Status: Active » Closed (cannot reproduce)

No further information provided. If this remains an issue please provide steps for reproducing it, as requested.