Provide a generic relationship handler for products

Not sure, but you're using Commerce Kickstart 2.x - moved this to the correct queue.

Ok, then it must be Commerce Backoffice. Commerce by itself only ever lists product entities in the Store > Products View.

Can you provide screenshots?

indeed, this issue exists.
I could reproduce it in a custom Drupal Commerce with a custom Product reference Field - field_xxx (where xxx != product - the default product reference Field)
So what actually happens is that the view is broken as the View Relationship it's broken - it doesn't exist.

I think we need at least some documentation about this on:
- http://drupal.org/project/commerce_backoffice
- http://www.drupalcommerce.org/commerce-kickstart-2/product-management-ov...

What about having a more generic Relationship as "Taxonomy terms on node" Relationship handler?

Having a relationship handler that can guess the field name for you would be great.
I don't know if it's possible or how much work it would be.
Changing to feature request.

here is patch that build such a Relationship Handler (inspired by "Taxonomy terms on node")
the patch also changes the "Commerce Backoffice: Products" View - uses the new Handler.

vasike, I applied your patch, to no avail. I still cannot add the relevant relationship in the view (I reverted the view to its default state and cleared all caches). Unfortunately this means the "quick edit" functionality will not work properly at all... Is there some workaround in the meantime?

I would gladly help with the patch, if only I were knowledgeable enough about views handlers...

The missing relation handler also affects the commerce_backoffice_product_variations view, this is the view used to render the quick edit.

with the patch from #10 commerce_backoffice_products has the generic relationship. i just needed to edit the new relationship and check the checkbox for the product reference field that i used.

i still had to add the new relationship and contextual filter to the view used by quickedit commerce_backoffice_product_variations but now it seems to work as expected.

here are the exports of the adapted views:

indeed. the previous patch was far for complete. thank you all.

there is a new patch that should covers also the the quick edit View.

It seems there was also something wrong with the "All taxonomy terms" associated with a product - won't work within relationship - with this patch it should be fixed.

i tested this new patch and still had to edit the new relationship and select the correct field in both views manually.

sadly this time, even though the correct products show up in quickedit, the status and price fields arent working.

interestingly the quickedit works when i use this implementation: https://github.com/rosenstrauch/commerce_backoffice_quickedit_ui that gives us all fields available there optionally.

@discipolo : thank you Sir.
indeed there was an issue getting the product variations entities for the quick edit form Views field - the relationship wasn't used.

there is a new patch that should solve this.

forgot the patch.

I've got to mark this as needs work. I still have to enable the proper field on the relationship. We should be able to find this in code, so when the view import it dynamically chooses first (as it should be safe to assume first product reference field == proper one.)

Here is re-rolled patch. Key difference is that if $this->options['product_reference'] is not set, it'll use the first key in the $options array. It also marks this field as required, since it is - otherwise you don't see products in the View.

Otherwise kudos on that handler, vasike.

:) Forgot the patch

excitedly testing this

@mglaman : thank for your help.
But i won't agree with your addition, this means back to a NOT generic relationship handler for products.

So with this option required will restrict the usage to the specific product reference fields and this relationship portability.

Without having a product reference field all the product reference fields found for the content types should be used for the relationship.
So maybe there should be somthing to be done - for multiple fields defined.

how about selecting any reference field by default and not marking them as required

But, vasike, without selecting a product reference field no products displayed - at all. Or, maybe it was because I don't have field_product as the product reference field? See #2298111: Backoffice assumes product reference field is "field_product"

@discipolo, @mglaman: thank you for your support.
now i know exactly what it's needed. soon i'll post a new patch that should work for any existing product reference field.

and there is a new patch that should solve the problems with the custom product reference fields.

So using this relationship with no product reference field selected will use all the product reference fields it finds.

vasike, awesome! I will test this out later today

+++ b/includes/views/handlers/commerce_backoffice_handler_relationship_node_product_data.inc
@@ -0,0 +1,85 @@
+    // Use the selected product reference fields or all if no selection.
+    if ($product_references = array_filter($this->options['product_references'])) {
+    }
+    else {
+      $product_references = array_keys(commerce_info_fields('commerce_product_reference', 'node'));
+    }

Only thing I'd say is have lines 56/57 replaced by creating the $product_references variable via array_filter, and line 58 would be if(!product_references)

Applied this patch to Commerce Backoffice 7.x-1.4 and it does the trick for me.

I had added some custom product reference fields to a product display and was not seeing those in the Backoffice Product listing view .

This patch made those missing products show up.

the patch from #28 doesnt add the new file for me (error: includes/views/handlers/commerce_backoffice_handler_relationship_node_product_data.inc: No such file or directory) so i recreated it.
didnt attempt the improvements from #29 yet

The project I'm working on also has a product reference field with a different name so the quick edit functionality broke. I can confirm the patch from #28 works as intended, everythink works OK now.

I have re-rolled the patch and included the proposed changes from #29.

Can we get this reviewed and committed to 7.x-1.x ASAP? I think a lot of (new) non-kickstart sites can have a lot of trouble with the product backoffice management page with this problem.

Whoops, seems the re-rolled patch didn't contain everything. This one (#33) should work.

+++ b/includes/views/handlers/commerce_backoffice_handler_relationship_node_product_data.inc
@@ -0,0 +1,87 @@
+    ¶
...
+    ¶
...
+    ¶

Going to be *that* guy, but white spaces

@mglaman, seems I have (or well, Notepad++ has) done it wrong all my life. Thanks for the tip!

See attached the updated patch.

+++ b/includes/views/handlers/commerce_backoffice_handler_relationship_node_product_data.inc
@@ -0,0 +1,87 @@
+    $product_references = array_filter($this->options['product_references'];

missing parenthesis

Thanks for the patch, I had some issues applying the patch with the latest dev (or 1.5).

There was just one issue with the product info file as there is now a files[] entry for a test file.

Re-rolled the patch against latest dev.

Oops, didn't include the actual class file, my bad!

Re-rolled with the missing file.