Views relationship for votingapi missing in node views

The attached patch takes a more generic approach created views relationships for every content based entity type installed on the system. The patch in #2 provided node, comment, and user relationships and assumed all were installed on the system.

The following relationships are added for each entity type, votingapi result function (average, sum, count), and vote type (up, down, ...):

1. Entity type & Result Function: One entity to many vote results relationship. Example: 'Vote Result "Sum" for content items'. Usage: This will produce multiple rows for a single node.
   

   NID	Vote type	Vote Value
   1	Up	12
   1	Down	6

2. Entity type & Result Function & Vote Type: Flattened relationship for each vote type. Example: 'Vote Result "Sum" for content items: Like/Up/Yes vote'. Usage: Provide a column for each result sum.
   

   NID	Up	Down
   1	12	6

Patch update - added back base table definition per patch #2.

With the patch from #5 applied, I tried to create a "Most popular" view on a site with the current state of core's 8.2.x branch.

I observed two issues:

1. When adding a relationship, the various vote result options each appeared 3 times
2. After adding the relationship "Vote Result "Average" for content items", a fatal error occurred when saving the view: Drupal\Core\Config\ConfigValueException: node_vote_result_vote_field_average:node.field_rating key contains a dot which is not supported. in Drupal\Core\Config\ConfigBase->validateKeys()

The second issue seems to be related to #2780869: Cannot save a view where a filter value option contains a period

I updated the patch from #5, I was able to remove some duplicate code and fixed both issues mentioned in #6.

The fatal error was easy to overcome by not using the period in the views handler key. There were not many duplicates, there is one relationship added for each field type and for each vote type, so the product is a little large and confusing. For the fields I added the field name into the label so that you can understand what relationship you are targeting.

Support for entity types other than content would also be great to have.
I'm using a contact form together with Contact storage to collect user reviews. After that those reviews can be rated. Since it's neither a content entity nor translatable, a relationship doesn't appear in Views.
Here is the code from #5 with the check:

diff --git a/votingapi.views.inc b/votingapi.views.inc
new file mode 100644
+  foreach ($entity_types as $entity_type_id => $entity_type) {
...
+    // Limit to content entity types.
+    if ($entity_type->getGroup() == 'content' &&
+        $entity_type->isTranslatable() &&
+        $entity_type->getKey('id')) {
+      $views_entity_types[$entity_type_id] = $entity_type;
+    }
+  }

Someone made any progress on views integration?

I just recently had the need of relationships for Voting API and tested the votingapi-views-relationships-for-vote-result-2731101-7.patch which works fine for me.

Therefor to the developers and maintainers of Voting API, I also ask if you can include the patch so that those who come here for the same reason don't need to go through patching needlessly.

Setting status back to "Needs review" so that testbots and maintainers will see this issue (see https://www.drupal.org/node/156119 for more info on status)

We have updated the patch from #7 with the ability to sort the views by voting result. If an entity has no votes, it will be sorted to between entities with positive and negative results (as if it's result is 0).

What about in search_api views I cannot see vote relationships?

I'm getting error on page

Notice: Undefined property: Drupal\search_api\Plugin\views\query\SearchApiQuery::$tables in votingapi_views_query_alter() (line 83 of modules/contrib/votingapi/votingapi.module).
Warning: Invalid argument supplied for foreach() in votingapi_views_query_alter() (line 83 of modules/contrib/votingapi/votingapi.module).

Just adding this patch as a quick workaround so am not getting issues with search api views.

Just adding this patch with a better workaround so am not getting issues with search api views and others.

Attached patch is based on the one from #16. It removes the piece of code mentioned in #8, so the views integration works with contact messages.

The patch from #17 was broken, attaching the proper one.

Maybe I missed something, but I have tried several patches : #7, #16 and #18... none of them could solve my sort problem.

Drupal 8.4-dev
votingapi 8.3.x-dev

I have created a content type (node) with a voting field:

Vote plugin: 5 stars rating
Vote type: Normal vote (default)=>points
Number of allowed values: 1

And a view to list this content type (no relationship).
I have tried several combination of the field: read-only (yes/no), show result (yes/no), Show own vote (yes/no) without success

Please test. I recreated patch, but I didn't test it.

I have added relationship but sorting not really working.

can you write all the dependencies and step-by-step instruction to reproduce the problem?

I have tested the last patch with a combination of votingapi widgets module (dev version), which populates tables votingapi_results and votingapi_vote correctly. Or maybe should I go through all these patches and apply them 1 by 1?

Maybe, you have to test on the version 8.x-3.x-dev of the module?

@drupalgin I test on Voting API 8.x-3.x-dev.

Hello, to apply vote relationships on a view you can use this patch. It's from patch #7.

When adding a relationship you have to select "Vote Result "Average" for content items: Normal vote" or other if you are working with votingapi_widgets module.

If you want to sort ASC or DESC you have to select Vote result: Value and set sort order to top (it have to be first).

Please test it.

The patch in #29 correctly solves the issue of implementing a relationship + view fields. I tested it out and it works as stated.

Also tested patch in #29, can verify that it's working. Can we have this rolled back into the module?

I have also installed and tested patch #29 successfully.