Determine the ability to delete a product

I'm not following everything in this project, so hope I'm on-topic here.

Are you designing a system that can be audited? Because your question raises the issue that an auditable system would require more than just preventing node deletions, eg:
-- transactions cannot be deleted
-- product title, SKU, customer info, is stored onto the transaction in case these are changed on the live entities
-- there is a reconciliation process

I won't go as far as to say that commerce needs to be 21 CFR Part II compliant, but my opinions are certainly influenced by working with compliant systems.

(Note, Drupal in general is well short of 21 CFR Part II compliance as it allows content to be deleted. Compliant systems I've seen actually have a field called "deleted" but never delete the data!

My thoughts are that commerce API should be a strict gatekeeper to the data changes, and to make sure other modules can track what is going on.

If I was given the task to lock down commerce on a Drupal site:
-- It would be nice to have commerce tables in a separate database.
-- Every time there was a commerce related data change in the system, I want a hook_commerce_audit() with a unique "key" for that event plus all the relevant data. I'd then choose how to record that information.

The "key" might be "TRANSDELETE" or "ORDER001" or "commerce_blah_function" (ie. the name of the function that is performing the update). It doesn't matter as long as everything that happens can be traced back to where it happened!

hook_commerce_audit() could then be triggered on Drupal stuff like user and node events. But actually preventing a node deletion is outside this scope, couldn't you just get a 3rd party contrib to do it?

Identifying every commerce event like this might sound a bit nasty. But to be honest, if you've designed your interface to the database properly, it would be quite clean. If you can have the commerce tables in a separate database, even better, you may be able (I guess) to prevent the 3rd party contrib from accessing this database directly.

So you might have an product reference field on the order entity ? uhm... doesn't this tie the order module to product ?

As for deletion and as you say, since you store the SKU on the order there should be no problem to delete a product...But changing the SKU seems not to be an option. If someone wants to change an sku, they just should "unpublish" the product, clone it change the sku and "publish" the copy
I suggested having a flag field like sime said (and like node unpublished ).

I for one believe it's a bad idea to delete things. Customers frequently make mistakes, and it would be much easier to resolve these by removing a deleted indicator.

I don't think it's wrong to allow a Product to be deleted, as long as there's no transaction history. This allows you to make mistakes while you get things setup properly. Consider the impact of importing products. However, once there is history, you should not delete it.

You might want to consider two flags.

1. Active - (deleted = false)
2. Sold

I think Active works better than deleted. Delete implies that it's gone forever. However, you can undelete a SKU by changing the flag.

The sold flag would allow you to do some kitting. You can display the individual products in the kit, but you can only add the kit SKU to the order. Another use case could be having the iPad on your site, but sold = false and you have a note in the description that says "For Sale April 3rd - Please come back then".

The TODO in commerce_product.controller.inc is still hanging. Has any decision been made on this ?

PS: deleted the "products" tag since it's already on component field