EntityListController::getOperations() should respect access checks

Let's just retitle this.

I have a feeling that we don't have tests for every single config entity for those operation links, so will probably require some manual testing at least and maybe some additional tests? Not sure how useful it is if we have tests for this for every config entity?

+++ b/core/modules/views/lib/Drupal/views/ViewAccessController.phpundefined
@@ -0,0 +1,26 @@
+  public function access(EntityInterface $entity, $operation, $langcode = LANGUAGE_DEFAULT, User $account = NULL) {
+    return user_access('administer views', $account);
+  }

Should we maybe limit this to edit and delete?

So my question is, should there be access checks for every operation, or just edit and delete?

Maybe skip just "view", as you would need more context (like the current active display) in order to do it properly.

#8: getopterations-access-1995048-8.patch queued for re-testing.

Changing component. I think with the additional tests added in #2010290: Editing a config entity from a listing page results in a 'page not found', we're in a better shape to do this and not break all edit links again as we did before ;)

Simple re-roll.

Will need more changes, e.g. the contact category list controller doesn't need to remove them again, but I want to get the NG conversion in first.

Lots of random failures in there, but we're missing an access controller for actions I think.

Rerolled and added an ActionAccessController.

Let's see how far this gets us.

Looks good, I expect the shortcut and picture list controllers are altering operations that aren't set anymore? I guess we're missing test coverage there?

Also, at least the contact category controller does access checks too, those can be removed now. Others might be similar.

#1696660: Add an entity access API for single entity access says we should use 'update' not 'edit'. I disagree, but it's apparently too late.

Menu, PictureMapping, CustomBlockType were missing access controllers.
See #1984702: Convert menu.module's page callbacks to Controllers for upcoming changes to menu, which would have exposed this error.

I didn't yet check for double access checks (like contact category).

Okay, I went through every instance of getOperations() and cleaned all of them up.

I think we should be done.

Brainfart.

Looks great!

+++ b/core/modules/views_ui/lib/Drupal/views_ui/ViewListController.phpundefined
@@ -169,10 +169,6 @@ public function buildOperations(EntityInterface $entity) {
-    // Use the dropbutton #type.
-    unset($build['#theme']);
-    $build['#type'] = 'dropbutton';

How is this related?

Talked about that part with @timplunkett and it's basically dead code that's being removed there. #theme isn't even set at this point, and #type dropbutton and operations is almost the same except a slightly different #theme suggestion. It's a bit out of scope here, but opening a separate issue to remove three lines of no-op code seems overkill.

So, given that we added a fair amount of test coverage for these operation links in the /edit issue., I think is ready to go in.

Committed 4f8b8a5 and pushed to 8.x. Thanks!

Lets update https://drupal.org/node/2019575...

Also opened #2029319: ConfigEntityListController::getOperations adds 'enable' and 'disable' without checking access for discussion.

Updated https://drupal.org/node/1799642, the other one was just about altering the operations.

Filter was missing an access controller. Was going to add it in #2012312: Remove legacy code from filter.module, moving only the relevant parts to an issue.

We're missing tests, no sense in doing this here. See you in #2030129: FilterFormat has no access controller.