This issue is probably related to the other SKU change related issues that are out there, but I wasn't sure which to add this too as the descriptions didn't quite match the issue I have had to deal with.

The bottom line is my client was unable to update the stock levels for a product after changing the SKU.

I'm not entirely sure how they managed to do what they did, but they ended up with 2 products that shared a stock level.

From my investigation of revisions etc

Product 1 seemed to start with SKU: prod1
after several revisions the SKU was changed to prod2

Product 2 seemed to start with SKU: prod1

On admin/store/stock/list:
Product 1 had 2 entries with Product SKU showing as prod2 in both but the Stock SKU had entries for both prod1 and prod2.
Product 1 had 1 entry with a Product SKU but no Stock SKU listed

Any time Product 1 was edited and the /node/123/edit/stock page was visited the stock levels of Product 2 were displayed.

Any time Product 2 was edited and the /node/234/edit/stock page was visited the correct stock levels of Product 2 were displayed.

I fixed this by manual editing of the database changing nid to Product2s nid next to the SKU prod1 in the uc_product_stock

and then I also had to edit the uc_products table and find all entries for Product 1 and edit the SKU for the older revisions, once all entries showed the newer SKU the /node/123/edit/stock page now showed the correct SKU and stock level and so updating was possible once more.

This is not an ideal fix, but I was confident that the changes made to the SKU were made before the site actually went live and so no historical data was required to be kept.

Is there a way to change the form on /node/123/edit/stock so that it grabs the newest revision rather than the oldest revision. Not sure how this will affect the other issues, but I thought the investigation may add some new light on the subject.

#11 ubercart-stock_page_node_revision_fix-1637336-11-7.x-3.x.patch741 bytesm.stenta
PASSED: [[SimpleTest]]: [MySQL] 2,943 pass(es). View
#10 ubercart-stock_page_node_revision_fix-1637336-10-7.x-3.x.patch820 bytesm.stenta
PASSED: [[SimpleTest]]: [MySQL] 2,945 pass(es). View
#10 ubercart-stock_page_node_revision_fix-1637336-10-6.x-2.x.patch697 bytesm.stenta
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch ubercart-stock_page_node_revision_fix-1637336-10-6.x-2.x.patch. Unable to apply patch. See the log in the details link for more information. View
#3 ubercart-stock_page_node_revision_fix-1637336-3.patch702 bytesmitrpaka
PASSED: [[SimpleTest]]: [MySQL] 1,709 pass(es). View


longwave’s picture

This is similar to #1011068: Changing SKU on a node to a previously used SKU on a different node leads to bogus stock information (wrong reports) but perhaps with an additional bug where node revisions are not handled correctly.

the_g_bomb’s picture

Yes similar, but also similar to #745912: Stock values lost when SKU is altered, #423262: Stock information not deleted with node and #381464: Orphan stock information in the database leading to wrong reports and those were just the obvious ones. I can't be sure of the exact steps the customer took to create this issue, so it is possible that deletions were involved.

Either way, updates and revisions seem to be an issue.

mitrpaka’s picture

Version: 6.x-2.9 » 6.x-2.x-dev
Status: Active » Needs review
702 bytes
PASSED: [[SimpleTest]]: [MySQL] 1,709 pass(es). View

Here is the fix for node revisions issue on products stock page (if multiple revisions of the node exist)

Doesn't take any side for SKU updates issues listed above.

the_g_bomb’s picture

Patch applies cleanly and the logic of it makes sense, will try and test it on some troublesome data, that hasn't been cleaned up when I get the chance. Thanks.

iwant2fly’s picture

Version: 6.x-2.x-dev » 7.x-3.2
Status: Needs review » Active

This same thing is happening in 7.x-3.2 on my install.

After changing the SKU on a product, the SKU on the stock, is unchanged. Is there a way to manually override the stock SKU?

Sorry I made a duplicate entry here: I didn't realize it was still considered a duplicate when it was a different version.

stuchl4n3k’s picture

I also noticed, that when you use Product Stock level field in views (e.g. on catalog page), the level is actually joined using nid on node table, instead of using SKU over products table (

  // Attach stock data to nodes.
  $data['uc_product_stock']['table']['join']['node'] = array(
    'left_field' => 'nid',
    'field' => 'nid',

I believe it should be something like this (INNER joins wouldn't hurt, would they?):

  // Attach stock data to nodes.
  $data['uc_product_stock']['table']['join']['node'] = array(
    'type' => 'inner',
    'left_table' => 'uc_products',
    'left_field' => 'model',
    'field' => 'sku',

  $data['uc_product_stock']['table']['join']['uc_products'] = array(
    'type' => 'inner',
    'left_field' => 'vid',
    'field' => 'vid',
TR’s picture

nid is the only unique identifier for products. Unfortunately SKUs are not unique. This something that needs to be made when uc_stock is re-architected for D8.

longwave’s picture

daveparrish’s picture

#3 works well for me. I came up with the same patch independently and it solves my problem with stocks.

My problem was that the stock edit page would show an old model/sku and the stocks would be wrong.

I think this patch should be applied.

EDIT: I realized my issue was on Drupal 6 so I created an issue for that version with a patch.

m.stenta’s picture

Version: 7.x-3.2 » 7.x-3.x-dev
Status: Active » Needs review
697 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch ubercart-stock_page_node_revision_fix-1637336-10-6.x-2.x.patch. Unable to apply patch. See the log in the details link for more information. View
820 bytes
PASSED: [[SimpleTest]]: [MySQL] 2,945 pass(es). View

I rerolled the patch from #3 for both 7.x-3.x and 6.x-2.x.

I made one small change: I removed "vid" from the fields that are selected in the query. It's not necessary, since we're using db_result() (in 6.x-2.x) and ->fetchField() (in 7.x-3.x) to just grab the first field... so "vid" is ignored anyway.

With this patch, the uc_product_get_models() function respects node revisions, and retrieves the product model from the most recent product revision.

m.stenta’s picture

741 bytes
PASSED: [[SimpleTest]]: [MySQL] 2,943 pass(es). View

Oops! The 7.x-3.x patch above is bad (there was a merge conflict, and I didn't resolve before exporting the patch).

Attached is the patch I meant to upload for 7.x-3.x.

The 6.x-2.x patch in the previous comment is still good, and also ready for review.

stewart.adam’s picture

Status: Needs review » Reviewed & tested by the community

Works for me!