Remaining tasks for "edit block $type" permissions

It looks as though (2) from the issue description was already done on the parent issue, just not checked off the list.

In Drupal\block_content\BlockContentType, I see

  public function blockTypePermissions() {
    return $this->generatePermissions(BlockContentType::loadMultiple(), [$this, 'buildPermissions']);
  }

as recommended in the change record.

I also tested:

1. Install Drupal with the current 10.1.x and the demo_umami profile.
2. On /en/admin/people/permissions/module/block_content, grant all "edit block type" permissions to the Editor role.
3. Use /en/admin/config/development/configuration/single/export to inspect the dependencies for the role.

The dependencies were added.

The "Manage Permissions" tab was added in #3253955: Let modules opt in to the bundle-specific permissions form. But when that issue was fixed, there were no per-block-type permissions from the block_content module. There might be such permissions from other modules, such as Configuration Translation or Layout Builder. Since there may or may not be per-block-type permissions, the BlockContentType entity specifies an access check to avoid allowing access to an empty page, or generating links to it.

The change record explains how to handle this: specify one of two route providers in the entity annotations, depending on whether the check is needed. I have made the required change in the MR for this issue.

Item (1) from the issue description relates to the "create block $type" permissions. Some patches on the parent issue added these permissions, but the final version does not. The create permissions were moved to a child issue (sibling of this one): #3213736: Add "create block $type" permissions.

Again, the task should have been removed from the list in the issue summary of the parent issue.

I have addressed all three items, so this issue is now ready for review.

P.S. I copied some comments from the parent issue to #3213736: Add "create block $type" permissions.

AaronMcHale:

Thanks for testing. Did you also review the +1/-1 change in the MR?

Please re-test the contextual links. In the Standard profile, the Content Editor role already has permission to use contextual links. That and permission to edit Test blocks should be enough, and it works as expected in my testing:

It is also listed as one of the "completed tasks" on the parent issue. (Search that issue for "contextual".)

Also, you tested the functionality of the parent issue, but you did not test the change made in this one, which affects access to the Permissions form (tab, local task) for the block types.

1. A user with the "administer permissions" permission should have access to Manage Permissions: /admin/structure/block/block-content/manage/basic/permissions.
2. That page should appear as a tab (local task) on the block-type page.
3. Links to the permissions forms should be available in the Operations column of /admin/structure/block/block-content/types.

All of that should function the same with or without the change in this issue. The change here is to skip the unnecessary test that there is at least one permission to manage. Maybe the easiest way to test that is to hack Drupal\user\Form\EntityPermissionsForm::access() so that it always returns AccessResult::forbidden(). With 10.1.x, even the administrator role cannot access the permissions form. With the patch, anyone with the "administer permissions" permission should have access.

In my testing, all of that works.

Back to NR.