Duplication of node when manually adjusting stock levels

In the uc_product_stock table are the SKUs duplicated as well?

There are some known issues with the stock module, see http://drupal.org/project/issues/ubercart?text=stock+sku

Longwave - SKUs aren't being duplicated but NIDs are.

So you are changing the SKU on the product? Can you test the patch in #1011068: Changing SKU on a node to a previously used SKU on a different node leads to bogus stock information (wrong reports) and see if that helps?

So - I'm working with Kathy and John on this. I've added the patch but the problem still exists. I duplicated the issue by doing this:

In an existing product, edit the SKU (stock level set at 100)

Save new SKU, check stock level: now it is zero

Recheck stock level a: now zero.

Reset stock level to 100.

Check product view: now listed twice (same NID when you go to edit either one)

Thinking that it should be updating the uc_stock table when an SKU changes, shouldn't it? Seems like that's how the data is getting screwy.

Jason

I think I see the source of the issue, but am not sure if this captures it well enough.

the primary key for uc_product_stock table is the SKU(model) - that's how records there are searched/modified/added

when hook_update is called in the uc_product.module it only updates uc_product - not uc_product_stock - so the primary key becomes useless in the uc_product_stock table

I'm thinking that if there's a function to check for that (original) SKU in the uc_product_stock table when hook_update is called, that record could be updated as well with the new SKU - preserving the stock records.

I'll be looking at that as a possibility more today. @longwave - what do you think?

Jason

I think this is being addressed by #423262: Stock information not deleted with node?

There are a bunch of inter-related issues regarding SKUs vs nids for use in stock control, and when fixing this there are things to consider such as what if the new SKU is already in use: do you warn about this, merge the stock levels, or some other option? Product options make this even more complicated. Perhaps we should have a summary issue with all the stock problems listed in one place, and think about fixing them all in one go; I'm wary that fixing one particular stock issue will just cause unexpected problems elsewhere.

Node vs Sku is a very serious problem. I'm for a sku being absolutely unique in relation to a product title. On the other hand, we already have a nid as a unique identifier. For most shop admins skt is an alien and unnecessary thing.

This is basically a duplicate of #381464: Orphan stock information in the database leading to wrong reports