Strange disconnect between attributes and uc_product_attributes

Well, first of all, your second image shows *options*, not attributes. Second, there is nothing wrong with having a blank label field for aid 5 and 6 as shown in your first image - all that means is that you didn't assign a label name to the attribute when you created it (label is not a required field when creating an attribute). Attributes have both a name and a label, and your post doesn't tell me what you changed - "changed the value of an attribute" doesn't mean anything to me since attributes don't have values.

In other words, I have no idea what you think the "bug" is in this case - it seems to me that you're not seeing what you expect because you don't understand what you *should* be seeing and you don't understand how the attribute data is stored across the Ubercart database tables. Is there anything specific that doesn't work properly? And can you describe the steps you took so we can try to reproduce your situation and see if it really is a problem?

Labels are the text displayed to the user on the product view form, and can be unique to each product using that attribute. Name is the internal attribute name, and is the same for all products using that attribute.

You're missing step 2.1) Save form.

I can't reproduce what you've described. When I follow those steps, including step 2.1, the label in uc_product_attributes is changed for that product and the modified label is shown on the product view page.

uc_attribute_options is the table that holds option names.

I had the same issue as gone404 when editing the attribute label. The label appeared changed on the admin/store/attributes Overview list, however did not refresh on the products page even when opened in a different browser.
I "fixed" it by deleting the attribute from the product, then re-adding the attribute to the product and, viola! We have our edit!

So, in troubleshooting the issue, more info...
As it is a dev site, all acceleration is off and it is not an upgrade-started from a clean install.
We have caching turned off, too, but flushing all caches did not work either. (I tried this before removing the attribute from the product ;)
I attached module list for version and compatibility reference.
BTW, we are on UC 6.x-2.3 and D 6.19.
k thx bai!

ArtScientific Creative Solutions loves theming Drupal and Ubercart!

I also observed the same behavior as gone404. Changing the attribute label in the admin interface did not change the stored value in uc_product_attributes database. I noticed this when I created view that placed the 'add to cart' form in a block and the labels did not update to reflect changes made under admin/store/attributes. I flushed all caches with no change and I temporarily got around it by changing the values manually in phpMyAdmin.

I'm curious if it has to do with the fact that I added the attributes manually to a specific product node, rather than attaching attributes to a class. I noticed that the hook_nodeapi implementation in the uc_attribute.module file selects from uc_class_attributes (which for me is empty) to insert into uc_product_attributes.

gone404 if you can confirm that you manually added the attributes instead of adding them to a class first that might help ferret out the cause.

p.s. I changed this to an active bug report to see if it can get some brief attention again.

I still cannot reproduce this. Feel free to reopen the issue if you can provide steps to reproduce the problem in the current Ubercart release.

Still having the problem as described above in uc_attribute 6.x-2.4. The problem is quite obvious when looking at the uc_attribute_form_submit function:

/**
 * @see uc_attribute_add_form()
 */
function uc_attribute_form_submit($form, &$form_state) {
  if (!empty($form_state['values']['aid'])) {
    db_query("UPDATE {uc_attributes} SET name = '%s', label = '%s', ordering = %d, required = %d, display = %d, description = '%s' WHERE aid = %d", $form_state['values']['name'], $form_state['values']['label'], $form_state['values']['ordering'], $form_state['values']['required'], $form_state['values']['display'], $form_state['values']['description'], $form_state['values']['aid']);
  }
  else {
    db_query("INSERT INTO {uc_attributes} (name, label, ordering, required, display, description) VALUES ('%s', '%s', %d, %d, %d, '%s')", $form_state['values']['name'], $form_state['values']['label'], $form_state['values']['ordering'], $form_state['values']['required'], $form_state['values']['display'], $form_state['values']['description']);
    $form_state['values']['aid'] = db_last_insert_id('uc_attributes', 'aid');
  }

  $form_state['redirect'] = 'admin/store/attributes';
}

It updates the uc_attributes table allright, but it never ever touches the uc_product_attributes table. So when changing a label it never gets updated there... Same for the label in uc_class_attributes. IMHO, this function should be:

/**
 * @see uc_attribute_add_form()
 */
function uc_attribute_form_submit($form, &$form_state) {
  if (!empty($form_state['values']['aid'])) {
    db_query("UPDATE {uc_attributes} SET name = '%s', label = '%s', ordering = %d, required = %d, display = %d, description = '%s' WHERE aid = %d", $form_state['values']['name'], $form_state['values']['label'], $form_state['values']['ordering'], $form_state['values']['required'], $form_state['values']['display'], $form_state['values']['description'], $form_state['values']['aid']);
    // Assuming that this attribute is already in use, we update the instance labels as well! No rows will be affected here if the attribute is not in use.
    db_query("UPDATE {uc_product_attributes} SET label = '%s' WHERE aid = %d", $form_state['values']['label'], $form_state['values']['aid']);
    db_query("UPDATE {uc_class_attributes} SET label = '%s' WHERE aid = %d", $form_state['values']['label'], $form_state['values']['aid']);
  }
  else {
    db_query("INSERT INTO {uc_attributes} (name, label, ordering, required, display, description) VALUES ('%s', '%s', %d, %d, %d, '%s')", $form_state['values']['name'], $form_state['values']['label'], $form_state['values']['ordering'], $form_state['values']['required'], $form_state['values']['display'], $form_state['values']['description']);
    $form_state['values']['aid'] = db_last_insert_id('uc_attributes', 'aid');
  }

  $form_state['redirect'] = 'admin/store/attributes';
}

Which is exactly what I did to fix this...

No, that would not be a good thing to do. If you change a product label it should NOT automatically affect all existing products - that amounts to destroying data. We've discussed this in detail in another thread where the question was about changing the set of options that an attribute has. If you want the ability to push the label change out to all products that are currently using that label, then there should be a dialog box where there admin has to confirm the overwrite of the existing data. The uc_product_attributes table is not just a relation, it holds product-specific values. We wouldn't need a label column in this table if all products had to share the same label as you propose.