Remove the cardinality setting from attribute reference fields

Needs work status is for patches. There is no any patch contributed (and tested to detect the work need).

Also, notice that each product variation it is a unique combination of IDs of all attributes on a given product. So, what you are trying to achieve is to place two combinations (variations) on the one variation at once. Obviously, that machine refuses to understand this.

I'd recommend to always choose select widget for the attributes form display. Though the checkboxes also should work if you never check both Extraspicy and Mediumspicy at once.

So, what you are trying to achieve is to place two combinations (variations) on the one variation at once. Obviously, that machine refuses to understand this.

One commerce_product_variant can have multiple commerce_product_attribute_values from the same commerce_product_attribute. I think this is a supported use case in DC2.

One commerce_product_variant can have multiple commerce_product_attribute_values from the same commerce_product_attribute.

Yes, but each attribute on a product variation must give only one value (ID) or NULL or - None - if the attribute is optional field. Actually, the - None - value is also a choice on the attribute, but you can't get it in the current Drupal Commerce without additional code customizations. So, taking one and only one attribute value from each attribute on a product variation we need to get a unique combination of the values (Extraspicy+Large, Mediumspicy+Large, Smallspicy+Large, Extraspicy+Tiny, Mediumspicy+Tiny, Smallspicy+Tiny, etc..)

Think of it in a practical way. Let say you make offer for a customer to buy a t-shirt of size M and having red and green color simultaneously.

What?

@drugan sounds like you are saying #7 is not a supported use case. I am fine with that if that's the fact. Then, the remaining of this issue is to remove the "checkbox" form widget, because "checkbox" implies multiple selection.

I agree, the checkbox widget for adding/editing variations might confuse some people. Actually, it was also me when I've started to explore Drupal Commerce. The radios widget is enough for those who want all attribute values visually displayed in the form.

But this is hardly might be fixed just because there are a lot of other widgets to choose from. You may create your own fancy widget for making awesome things and it will be displayed in the list, too. So, it is up to admin to decide which is appropriate for their needs.

Retitling to clarify what we need to do (as summarized in #11)

What about disabling the cardinality fields on the field UI?

I mean like this.

+  /** @var \Drupal\field_ui\Form\FieldStorageConfigEditForm $config_edit_form */
+  $config_edit_form = $form_state->getBuildInfo()['callback_object'];
+  /** @var \Drupal\field\Entity\FieldStorageConfig $field_storage_config */
+  $field_storage_config = $config_edit_form->getEntity();

We can shorten this to:

  /** @var \Drupal\field\FieldStorageConfigInterface $field_storage */
  $field_storage = $form_state->getFormObject()->getEntity();

+    $form['cardinality_container']['cardinality_number']['#disabled'] = TRUE;
+    // #states interferes with the disabled setting above.
+    unset($form['cardinality_container']['cardinality_number']['#states']);
+    $form['cardinality_container']['cardinality']['#disabled'] = TRUE;

Is there any benefit to #disabled => TRUE instead of #access => FALSE? Do we have a preference on disabling VS hiding?

My personal preference is #disabled over #access. It's less confusing to see the same form with some form elements being #disabled by someone than wondering if this is a different form or what happened to the cardinality setting. But I get confused easily. Anyway, #access FALSE makes the code 3 lines shorter, so I switched to that.

Note that in case we're adding the attribute value reference field manually to a variation, the cardinality field will still be there. Only the edit form is affected.

Tweaked the alter to always set the cardinality value to 1, therefore ensuring that the form self-corrects.

Thanks!