EntityViewsData adds Operations links to all entities, which won't work if the entity type has no list builder, leading to WSOD on some views

Its sad that operations are bound to the list class, but there is no way around that at the moment.

+++ b/core/modules/views/src/EntityViewsData.php
@@ -152,13 +152,18 @@ public function getViewsData() {
+    $list_builder_class = $this->entityType->getHandlerClass('list_builder');
+    if ($list_builder_class) {

I think it would be more elegant to use hasListBuilderClass() here.

Awesome, thanks!

We have the same issue in #1986606: Convert the comments administration screen to a view as well for comment. We are using dropbutton instead of operations links field there.

This actually should be tested (NW)
Looks we need to update docblocks hook_entity_operation & its alter to point that this hooks works only for entity types with list builder defined, otoh ...
There's EntityListBuilder that should be used when entity annotation "list_builder" is empty
Looks that require Berdir's mention

+++ b/core/modules/views/src/EntityViewsData.php
@@ -152,13 +152,17 @@ public function getViewsData() {
+    if ($this->entityType->hasListBuilderClass()) {
+      // The handler for entity operations needs the entity list builder; only
+      // provide it if there is one.

That's strange that operations require list builder.
Suppose handler should build operations without dependency on list builder.

The reason that operations are tied to list builders, is that in #1839516: Introduce entity operation providers it was decided we couldn't introduce a new type of entity handler to do this, because it would break existing list builders. That's why some entity types have to jump through hoops to get operations links.

Looks we need to update docblocks hook_entity_operation & its alter to point that this hooks works only for entity types with list builder defined, otoh ...

Maybe we should indeed. However, there is no standard to this kind of documentation. We always considered hooks to be part of our APIs. In Drupal 8 we seem to be moving to a point of view where we consider interfaces APIs and hooks are mere implementation details of those APIs. Next to that: if we document hook_entity_operation*() as being an implementation detail of EntityListBuilderInterface, do we explicitly disallow other APIs to directly invoke the hook?

I'm working on the tests.

if we document hook_entity_operation*() as being an implementation detail of EntityListBuilderInterface, do we explicitly disallow other APIs to directly invoke the hook?

yep, not a good idea

PS: EM::getListBuilder() should throw InvalidPluginDefinitionException if no list builder defined, so comment and term could be used for tests

PS: EM::getListBuilder() should throw InvalidPluginDefinitionException if no list builder defined, so comment and term could be used for tests

It already does that. See EntityManager::getHandler(). It's not documented on EntityMananagerInterface and I don't think this is good behavior, because a missing list builder does not make the plugin definition itself invalid, but that's another issue.

Marking #2587551: Selecting Operation Links for File Type View throws an Exception as a duplicate of this issue. @alexpott's patch over there includes an update function. This patch includes tests. Let's combine forces!

Also adding information to the summary to make this issue easier to find in search.

Also @alexpott and I agreed on making this an RC target.

(Removing accidentally copied line from the summary.)

Seems like we should have an actual test of the functionality (the \Drupal\views\Plugin\views\field\EntityOperations class itself) and not just of views data.
Also, why not put a hasListBuilderClass() check in there? Seems like that should exist regardless.

Just using the more explicit method name, no added tests.

Test for comments added in #2604618: Views operations dropbuttons do not work with Comment because it does not specify a list builder

We already have integration test coverage for the generic functionality: \Drupal\views\Tests\Handler\FieldEntityOperationsTest, IMHO we
don't need integration test coverage for every single bit.

Committed/pushed to 8.0.x, thanks!