This is something that may or may not be considered a bug, but in my opinion it is....

When setting up a product with product choices (like sizes for t-shirts) and managing the inventory at that level, you're able to choose what you want to do with that "product" when the inventory is depleted, you can leave it on the store but don't allow orders, remove it from the store, etc. Because I'm able to define this for each size (or option), it would lead me to believe that if I set it to "Remove from Store" when out of stock, that in the size drop down list on the product details page, it would no longer appear. For example, if I have a t-shirt A with sizes(inventory) of S(10), M(5) and L(0) that the drop down list would only show S and M. But when L has inventory, it would automatically show up in the option list. It doesn't appear to work that way on my site at least. Is this the way it is supposed to work?

I was looking at modding this, but basically the stored proc would need to be modified to check the inventory of the product choice (depending on what option you have selected for handling out of stock items) to determine if it's displayed. I got close to getting this feature completed but haven't had the chance to finalize it.

Hi Blue,

We have also considered making a mod for this, however, making the mod in a "general" way gets complicated fast.

Basically, when there is only 1 choice "type", you should be able to easily handle the mod the View.ascx file for that particular product choice type (radio button list, etc).

However, when this is extended to 2 choices, say size and color, things get interesting. The way bvc is designed and in my opinion it is a good design because of the flexibility/extensibility it allows, the choices are rendered individually within the VariantsDisplay control. The plug-in type architecture means that size and color cannot directly talk to each other preventing an easy way of controlling what is displayed based on the inventory. In a flow chart of a manner, the rendering is as follows:

VariantsDisplay (Master Control) ----> Size (The VariantsDisplay dynamically loads the appropriately View.ascx file which renders it individually) --> Color (Previous render is finished, VariantsDisplay now dynamically loads the View.ascx for the color choice)

Now, if a customer were to always choose the size before the color, while the mod is still complex, it is a bit more doable as you can modify the VariantDisplay to simple pass down previous choices and modifying the view.ascx.vb to look for/return these choices when rendering. However, it gets further complex if the customer now chooses a color before a size, because the size is rendered before the color. Now it still isn't quite so bad with only 2 choices, as you can pass the recently selected value to the variantdisplay in the "onclick" event that fires your ajax (assuming you'd use ajax) event behind the scenes. However, expand this to 3+ choices and you know need to enumerate all the product choices and retrieve their values prior to posting back. Further complicating the issue is that these choices out of the box can have 3 different display styles and can be customized to have other types.

Also coming into play as the number of the choice "types" increase is performance. If there are just 3 choice types with 3 choices each you are looking are verifying and acting upon the inventory data of 27 different combinations with an exponentially increase.

Therefore, depending on the assumptions you make, it can be a very easy mod (no change to the sp is needed) or it can get very complicated to implement it a general sense. I think if it were to be done, the best way of implementing it would be by creating a completely client side api that each individual choice "type" rendering module can call upon client side to show/hide the appropriate choices. Then in the product template, have it emit client side data on the inventory of the possible combinations ahead of time. This way if there is a lot of combination of the work is done while the page is initially loading rather than constantly recurring based on user input.