Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lukasss created an issue. See original summary.

lukasss’s picture

Status: Active » Needs review
lukasss’s picture

lukasss’s picture

Sorry! #3 not working
Here's a working patch #4

lukasss’s picture

Yesterday released a release including this feature.
Any progress here.

flocondetoile’s picture

Title: Support for variations in native editing form » Support for variations in native editing form to be compatible with Commerce 2.10
FileSize
4.6 KB

Patch #4 works fine with Drupal commerce 2.10 :-)
Attached a slighty udpated patch

- use $form_state->getFormObject()->getEntity() instead of $form_state->getBuildInfo()['callback_object']->getEntity()
- improve the $required parameter in the autoSkuNeeded() method : $required = $this->hasAutoSku() && ($this->entity->getSku() == '%AutoSku%');

Without the second condition, then a SKU is always updated and so if you use token based on the current date, your SKU change everytime someone update a variation.

Improve the title too.

lukasss’s picture

@flocondetoile, this look good!

zenimagine’s picture

Thank you, I applied the patch. It looks like it works, but I can not get the product ID and variation ID

[commerce_product_variation:product_id]-[commerce_product_variation:variation_id]

eldrupalista’s picture

It works for me fine. Thanks!

lukasss’s picture

Status: Needs review » Reviewed & tested by the community
themic8’s picture

Patch #6 does work.

Using commerce 2.11. and pulling the dev version of commerce_autosku

themic8’s picture

Tested both options and autosku and tokens work with the patch #6.

My issue was that I was not using the dev version of commerce_autosku.

Note there is also not a way to use the dev version with composer. I had to pull the git repo.

goodDenis’s picture

Status: Reviewed & tested by the community » Needs work

Thanks for the patch it works great with checkbox 'Allow each product to have multiple variations.'
But It hides variation for the product with 'single variation', so I cannot set the price or other variations fields.
I use 'drupal/commerce:2.11.0'

megadesk3000’s picture

FileSize
6.38 KB
2.57 KB

@zenimagine i ran into the same issue.

In my opinion the problem is, that this information (variation_id) is not available in commerce_autosku_commerce_product_variation_presave, since a new variation does not have an id at this point.
Since the variation id seems to be something, that should be definitively supported in an autosku generation process, i would suggest to move the functionality to hook_ENTITY_TYPE_insert and hook_ENTITY_TYPE_update instead of hook_ENTITY_TYPE_presave.

What do others think about that ?

I created a patch for that against the latest version of the module.

goodDenis’s picture

Status: Needs work » Needs review

@megadesk3000
Thanks! You patch works for me.

jwwj’s picture

The patch in #14 works if using the form widget "Inline Entity form - simple", but does not work if using the "Single variation (product information)" form widget. My guess is it would only require a similar block of code in commerce_autosku.module as the code below

function commerce_autosku_inline_entity_form_entity_form_alter(&$entity_form, &$form_state) {
  if ($entity_form['#entity_type'] == 'commerce_product_variation') {
    $entity = $entity_form['#entity'];
    commerce_autosku_select_mode($entity, $entity_form);
  }
}

but I can't figure out what hook to use in order to get it to fire when using the Single variation widget. Any thoughts?

jwwj’s picture

The patch in #14 works otherwise, but for me did not work when using products that only allow a single variation and use the Single variation form widget (commerce_product_single_variation). The attached patch should fix that, though I'm not sure it was the best way to fix the issue.

The patch includes the changes from #14, so it should be enough to just apply this patch to get all changes.

jwwj’s picture

Aah snap, sorry! Managed to add a bug, ignore 3004550-16-*.patch. Use 3004550-18-*.patch instead

jwwj’s picture

And one more... very sorry for the multiple patches, my quality control has failed me today :(

But still, only the last patch (#19) should be needed...

hatuhay’s picture

Status: Needs review » Reviewed & tested by the community

I can confirm patch worked for me, commerce 2.12

goodDenis’s picture

It works for me too, commerce 2.12
Thanks!

ohmdesbois’s picture

It seems that this is not the case with commerce 2.13

goodDenis’s picture

Status: Reviewed & tested by the community » Needs work

Yes, it looks like not working for a product with 'Allow each product to have multiple variations.'
I have a null value in the table commerce_product_variation_field_data 'sku' column after saving the product variation.

goodDenis’s picture

Status: Needs work » Reviewed & tested by the community

The patch doesn't work for me with "Automatically generate the SKU and hide the label field" option, on the "admin/commerce/config/product-variation-types/PRODUCT-TYPE/auto-sku" (maybe it is my local problem)
but it works with "Automatically generate the SKU if the SKU field is left empty"
tested with commerce 2.13.0

lukasss’s picture

Assigned: lukasss » Unassigned
Status: Reviewed & tested by the community » Needs work
zserno’s picture

Patch from #19 worked for me using Commerce 2.13. I can now use the 'Single Variation (Product information)' widget and leave the SKU field empty to get a generated SKU value.

(A fly in the ointment: on updating an existing product, I ran into this issue: #2974156: TypeError: Argument 1 passed to _editor_get_file_uuids_by_field() must implement interface Drupal\\Core\\Entity\\EntityInterface but patch #9 seems to be working.)

zenimagine’s picture

The last version of the module dates from 2017, now that Commerce is stable think you make an update and fix this problem ?

  • bojanz committed 7211623 on 8.x-2.x
    Issue #3004550 by lukasss, jwwj, megadesk3000, flocondetoile: Support...
bojanz’s picture

Status: Needs work » Fixed

I have been given commit access, so I've gone ahead and committed #19 (plus a few tweaks), as well as all other patches in the queue. I've also created a -dev release for testing. I won't have time to do work of my own, but I'll commit whatever patch the community provides. Since the module is/was completely non-functional, we can't break it more than it already is.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.