"This product does not have any attributes" on attributes set to display type "Checkbox".

That was by design. Read the original issue at http://drupal.org/node/400660#comment-1592722

I'm leaving this thread as "active" in case you want to make an argument for changing this behavior.

That comment you link to above says that it's "bad" to have a SKU / Stock Level for every combo of checkboxes.

What's wrong with different stock levels for every combo?

In a store that sells small/medium/large, red/blue t-shirts they certainly want to manage stock for

small red
small blue
medium red
medium blue
large red
large blue

Checkbox attributes are not mutually exclusive - you can have any, all, or none of the checkboxes checked. So in your case, neither the size nor the color should be checkbox attributes. You can't sell a shirt that is both Small and Medium. What you're trying to do is easily done using radio or select box attributes.

Simple math explains why it's "bad" to allow all checkbox combinations - one attribute with 10 checkboxes will have 1024 combinations and need 1024 separate SKUs. Two attributes with 10 checkboxes each increases that to 1,048,576 combinations. Combine that with some radio or select box attributes, and the situation quickly becomes unmanageable.

N! number of SKU's is definitely undesirable, but oftentimes a checkbox is a more appropriate UI element to allow for toggling the value of just one value for an attribute.

Simple case in point: Im building a site that sells back issues of their hard copy magazine. Ideally I would like to have one back issue product, with an attribute that says "Check this box to also buy the pdf of this back issue". File downloads in the feature section are tied to an SKU. So I want to have 2 SKU's, one with the box checked, and with with it unchecked. As it is I have to use a select box with Yes and No in order to accomplish this.

If I add 10 attributes to my product as selects, with 2 values each (on and off) I *still* end up with 1024 combinations, and I have an identical expression of the users preferences in the end.

The only value I see in limiting the number of SKU's is to prevent users from inadvertantly using a checkbox for a discrete set (like s,m, and l).

If we're concerned about user misuse, then I would suggest that a checkbox attribute can only have one checkbox, as @TR pointed out earlier, they are not mutually exclusive - therefore they are logically different attributes and should be treated as such. This would of course break existing useage of checkbox attributes so we probably wont see it happen.

Forgot to set this to active.

Perhaps a (per attribute?) option to "show select/radio attributes with only two options as a checkbox" would help, while not affecting current behaviour of actual checkbox attributes?

That'd be a good solution.. as "Related" checkboxes definitely still have a value as a grouping under one attribute.

What about checkboxes with only one option? That paradigm currently exists.. just like making a select box with only one option.. its "default" and its selected state. I guess it could be confusing if there were two ways to add checkbox 'selects'.

Two values might be difficult if you wanted to have one checkbox with no attribute label, and only the option label displayed, as the second 'disabled' state wouldn't necessarily have an attribute label *or* an option label.. (I guess the off state label could be the same as the on state label, or we could add jQuery magic and have the label toggle as well as the ui control)

I haven't looked at the code for attribute types, but how difficult would it be to add a fifth form control called "toggle" that required two options?, yet had one label?

I *have* dug into the 'cartesian product of too many attributes' issue at length last night and rewrote a bunch of the uc_product_adjustments_form(). I rolled a patch here so the performance problem is not as big of an issue: (i.e. if you have 10 attributes you can make adjustments without melting mysql), it'l http://drupal.org/node/375019#comment-3549864

In an ideal world there would be one last feature, which is to allow administrators to select which attributes they care about for adjustments. I have some attributes that do not add additional SKU's, but currently they have to.

Perhaps what I've been attempting is a valid case for enabling custom sku adjustments for products with display type "checkbox":

I have a store where products can have a number of add on products. I've been handling this by having a "base product" that is the main sku, and then all the optional products are additional purchases that can also be selected with a checkbox. For example:

Product: 3D model, sku 3DM_000001
Product option 1: texture set 1, "adjustment" sku: 3DM_000001_tex01
Product option 2: texture set 2, "adjustment" sku: 3DM_000001_tex02
Product option 3: animation rig, "adjustment" sku: 3DM_000001_anr01
Product option 4: animation 1, "adjustment" sku: 3DM_000001_anm01
Product option 5: animation 2, "adjustment" sku: 3DM_000001_anm02

Under this scenario, it makes perfect sense for a customer to purchase the main product, and every option, or even just one or two options without purchasing the main SKU (perhaps they already purchased the main product).

I've tried going into the db_query() command used by uc_product_adjustments_form() to exclude any products using checkboxes for display, and removing that exclusion. Everything still seems to work. Does anyone know anything that would break simply letting this go? The transactions still happen, and the order simply reports multiple skus for those purchases...

I'd like to ask if my use case for attributes, options & adjustments is an acceptable use, or do I need to modify my system?

Essentially, most people using Ubercart assume a "clothing store" frame of reference when it comes to product attributes and options, and therefore SKU adjustments are unique for a given product's combination of attributes and options. After all, a shirt ca not be both small and large at the same time...

However, when I set up this specific online store, I was thinking of my products more like a pizza restaurant: my products' only have a single attribute set, and that attribute set is the collection of "add-on" products that make sense for that product, like a collection of pizza toppings where a customer could add none, a few, or all of them to their pizza product order.

Within my frame of reference, it makes perfect sense for "onions" to be an optional add-on product for the "pizza" product, and it makes no sense for "pizza topping onions" to be a separate product.

Now, I'm not actually selling pizza; I'm selling media production assets for film and animation. In my scenario, a "3D Model" or "stock footage" are main products, but each and every one have a number of add-on products that only make sense within the context of that product. For example, a 3D model may have add-on products of texture sets, animation rigging, animations and so on... and these are specific to that 3D model only. Likewise, a stock footage media clip may have options such as the camera track used during filming, lens and camera information, captured HDR lighting of the environment of the clip and so on. Each of these add-on products only make sense to appear as options to that one specific stock footage clip.

As I mentioned above in post #9, I've tried removing the logic from the uc_product_adjustments_form() preventing products using option checkboxes from receiving SKU Adjustments. currently, I have a test product (a stock footage clip) where chckboxes provide access to about a half dozen add-ons. Is there any other logic that I need to be aware of, or will this "just work"?

Moving to 7.x-3.x.

Moving to 8.x-4.x.