Convert Filter routes to use entity access instead of permissions

+++ b/core/modules/filter/lib/Drupal/filter/FilterFormatAccessController.php
@@ -20,25 +20,26 @@ class FilterFormatAccessController extends EntityAccessController {
+      return $entity->isFallbackFormat() || $account->hasPermission($entity->getPermissionName());

It turns out this is redundant. FilterFormat::getPermissionName() checks isFallbackFormat() already. Restoring the previous !empty() check from before.

Also quoting the access bits like we do elsewhere.

+++ b/core/modules/filter/lib/Drupal/filter/FilterFormatAccessController.php
@@ -20,25 +20,27 @@ class FilterFormatAccessController extends EntityAccessController {
+    // All users are allowed to view the fallback filter.
+    if ($operation == 'view') {
+      $permission = $entity->getPermissionName();
+      return !empty($permission) && $account->hasPermission($permission);
     }

This looks a bit scary to me...

Is a text format really "viewed" when being presented in a text field widget? (No, it is not.)

Or isn't a text format much rather "viewed" when being listed on the administrative overview page that lists all available text formats?

→ I think we need to make a differentiation between "use" and "view".

Given recent entity access/operation API improvements, it might be much more simple now to introduce a new operation/access model of "use"?

Thanks, @Xano! — This looks good to me.

Somehow I assumed/hoped that a new access operation would have to be registered somewhere (so that available operations can be discovered and introspected by other services and developers), but based on this patch, that doesn't appear to be the case yet.

I also wondered whether the "administer filters" permission still kicks in somewhere, but I assume the "admin_permission" on the FilterFormat entity class annotation is automagically used and validated by the config entity system.

I also wondered whether the "administer filters" permission still kicks in somewhere, but I assume the "admin_permission" on the FilterFormat entity class annotation is automagically used and validated by the config entity system.

Yep, the parent::checkAccess call uses the admin_permission annotation, see EntityAccessController::checkAccess

+1 for RTBC

+++ b/core/modules/filter/lib/Drupal/filter/FilterFormatAccessController.php
@@ -19,26 +19,28 @@ class FilterFormatAccessController extends EntityAccessController {
+    if (in_array($operation, array('disable', 'view', 'update'))) {

Patch removes 'view' from almost everywhere, but not here. I realise this is just punting it to the parent, but is 'view' even used any more? If it's not, I'm not really convinced about the view/use change - leaves view hanging with no purpose at all, and this feels like an issue for most configuration entities.

This also removes the only place that _filter_disable_format_access is used, so the access_check.filter_disable service and corresponding Drupal\filter\Access\FormatDisableCheck class can be removed.

I must have accidentally clicked on another patch, I was just staring at FormatDisableCheck for another reason and thought I'd make a note here.

Thanks @Xano!

26: drupal_2101119_26.patch queued for re-testing.

26: drupal_2101119_26.patch queued for re-testing.

26: drupal_2101119_26.patch queued for re-testing.

Committed/pushed to 8.x, thanks!