The pattern for the SKU is set to [term-raw]-[nid]. I had nodes with their SKUs automatically generated just fine. Then I updated taxonomy terms, and tried re-saving the nodes and clearing cache, and the SKUs are still the old term name.

Comments

willvincent’s picture

willvincent commented
Status: Active » Closed (works as designed)

They're not being set to the new term because they already have a value.

The way the module works is that it will populate the field with the token value if there isn't already a value there, otherwise it populates it with the existing value. Then the field is hidden from the display.

I'll add this as a feature request so that you can decide whether to enable or disable overwriting existing sku values in the admin settings..

For the time being, you can change lines 68-74 of the uc_product_power_tools.module file from this:

  // Handle SKU field.
  switch ($class_settings['asku']) {
    case 1:
    //Do not overwrite SKU for existing products
    $form['base']['model']['#value']= isset($form['nid']['#value'])?$form['base']['model']['#default_value']:'';
    $form['base']['model']['#type']= 'hidden';
  }

to this:

  // Handle SKU field.
  switch ($class_settings['asku']) {
    case 1:
    //Overwrite SKU for existing products
    $form['base']['model']['#value'] = '';
    $form['base']['model']['#type'] = 'hidden';
  }
stacywray’s picture

stacywray commented

tcindie - thanks very much for explaining this and considering it as a feature!

arski’s picture

arski commented

"I'll add this as a feature request so that you can decide whether to enable or disable overwriting existing sku values in the admin settings.." <- have you? can't seem to find the issue? is this possible now or not?

arski’s picture

arski commented

PS - the fix you suggest above only sets the SKU value to an empty one and never takes the value from the replacement pattern :/