BlockContentAccessControlHandler requires access block library permission for update, delete and revisions operations

Hey @jenlampton, thanks for opening up a new issue to track your problem :)

First of all, can you let me know the machine name of the "Type 1: Edit content block" permissions - this pattern doesn't seem to match existing or new core permissions for editing block content entities:

They used to be:
Type 1: Edit any block content

And were updated to this in ✨ Add more granular block content permissions Fixed
Type 1: Edit custom block

The machine name (permission name?) of these is "edit any type_1 block content"

Do you have other modules providing these permissions? Perhaps https://drupal.org/project/block_content_permissions?

Secondly, core did not provide edit access to blocks via any other permission other than administer blocks, or the above permissions.

Looking at the access handler changes to the update operation from the above issue, you also need access block library to edit blocks.

This permission was added in an upgrade path, but only for roles with administer blocks - perhaps it should have added it to roles with the "edit any" permission too?

If we find that the permission was indeed the core "edit any type_1 block content" permission, then I think we missed an upgrade path for these roles.

We only added one for administer blocks but now all operations need access block library

> First of all, can you let me know the machine name of the "Type 1: Edit content block" permissions

The machine names for the permissions are as follows:

* Type 1: "Basic block: Edit content block" is edit any basic block content
* Type 2: "Card: Edit content block" is edit any card block content
* Type 3: "Promo Box: Edit content block" is edit any promo_box block content

> this pattern doesn't seem to match existing or new core permissions for editing block content entities:

That's strange, I copy/pasted these from the permissions page. Maybe it's different in D11 than in D10?

> Do you have other modules providing these permissions? Perhaps https://drupal.org/project/block_content_permissions?

Nope :)

> Looking at the access handler changes to the update operation from the above issue, you also need access block library to edit blocks.

This is my problem, I think. That completely defeats the purpose of the block-type edit access, doesn't it? If you don't want anyone to know about any blocks other than the type they can edit, why would you want them in the library?

Do people need access to the admin/content page in order to edit a single node type now too? If so maybe I missed that change...

> This permission was added in an upgrade path, but only for roles with administer blocks - perhaps it should have added it to roles with the "edit any" permission too?

No no no -- we definitely wouldn't want to grant people more permissions than they had before. That sounds like a potential security issue, no? We do, however, want them to have *the same* level of access as they had before.

> EDIT: Had a quick chat internally larowlan and the other option would be to remove the access block library check for these operations - there was a reason it was included but we need to do some issue forensics to figure out why!

I think this is the best option. I'll see if we can start working on that.

Had the same issue plus we incorporate Workbench in our installation, which we originally thought could be part of the problem but wasn't.

This solve worked for us with seemingly no implications: check the "Access the content blocks overview page. Get an overview all content blocks." It's near the bottom of "Block Content" on the permissions page (admin/people/permissions).

The change from Custom Block to Block Content has introduced a new requirement to access the content blocks page. Why this would deprive users' access to create or edit blocks... IDK.

@UTCbrij's research has pulled up this new permission requirement. Seems to solve the access issue for roles we have permitted to create/edit/delete custom blocks.

Yes, as part of ✨ Add more granular block content permissions Fixed the access block library permission was added and required for all operations (except viewing published blocks).

I agree with you all that this is not ideal and should be changed, people should be able to edit/delete/revert/delete things without necessarily being able to access the listing page). I'll push an MR that changes that, and see what fails.

Should we repurpose this to 'remove "access block library" permission from edit/delete access for block content'?

Test fails are all "Failed asserting that 403 is identical to 406." - I have no clue why or how or where this is set and why this would change.

Pipeline's green 🥳

MR appears unmergable.

Pretty intense merge conflicts, fixed them up and simplified the access control handler a lot. Also added some missing test cases.

Know that rebase wasn't easy. Changes seem to be good and glad to see that kernel tests get cleaned up some.

Followed the scenario of the issue summary.
Have a user with edit permission but not access block library
Verify I couldn't edit.

Applied MR and now I can.

Issue credits

Committed to 11.x and 10.2.x.

Doesn't apply to 10.1.x so will need a rework. I'm not sure if there will be another bugfix release for 10.1.x so will check with release managers.

On the basis that 🐛 Revert and Delete actions should not be available for the current revision Fixed didn't go to 10.1.x, let's mark this fixed in 10.2.0 only.

acbramley → closed merge request !5144

Automatically closed - issue fixed for 2 weeks with no activity.

This didn't fix create access. See 🐛 BlockContentAccessControlHandler requires access block library permission for create Needs review