Add more granular block content permissions

That plan seems reasonable, but now that ✨ Add Block Content revision UI Fixed is in - we might need to adjust for revision UI.

For #194 see see \Drupal\block_content\BlockContentPermissions::buildPermissions

It added:

• 'view any {type} block content history'
• 'revert and {type} block content revisions'
• 'delete any {type} block content revisions'

So we have those already.

Think this is ready for review now!

two things i've noticed, one observation and one question.

1) if a role has the permission to access the custom block library page plus the administer block types but NOT administer block library and NO permission is granted to create a new block the user with that role is still able to see the add custom block button. if the button is clicked i get the following help text which also seems about the wrong context: You have not created any block types yet. Go to the block type creation page to add a new block type. ( i actually see one custom block i've created with the block type basic block in the custom block library. In contrast if i add the same permissions for nodes the add content button is hidden.

2) i wonder about another detail. there is the permission Access block placement overview page. that permission works well with the first approach @larowlan created a POC for https://www.drupal.org/project/drupal/issues/3318112#comment-14941932 📌 [PP1] Move "Block layout" from Structure to Appearance Postponed where things are managed per task. in contrast in the second POC https://www.drupal.org/project/drupal/issues/3318112#comment-14941942 📌 [PP1] Move "Block layout" from Structure to Appearance Postponed things are managed by theme now. in the first approach there is a single overview page but with the second approach you basically have the same number of block placement overview pages as installed themes. would it make sense to be granular and add a permission for every installed theme? or is a single generalized permission enough?

i'll set the issue to needs work based on the first point.

@rkoller pushed a fix for #1

thanks @smustgrave i can confirm that your latest changes fixed #198.1 ✨ Add more granular block content permissions Fixed . When i access /admin/content/block-content the add custom block button is gone now as the user i had seen the button with before.

will test a few more permission combinations tomorrow but now it's sleep time for me.

i shouldn't try "just" one more thing when i wanted to go to bed. :( but had to test one more detail (which might go into node permissions as well). all permission changes made to the default content editor role.

for custom blocks
basic block: create new block content - checked
access the custom block library page - checked
administer block types -checked

the rest of the permissions in the custom block group is unchecked.

i am able to access the custom block library. i am able to add a custom block. on the custom block library no operations are available. and the block type column displays the block type of the available custom blocks in the list. in the block description column are just links. that might be my only nitpick. if clicked i get an access denied. that is completely correct behavior since the role doesnt have administer block library and a view custom block similar to view published content doesnt exist. but i wonder would it make sense in the described scenario not display links for the description pointing into an access denied page but instead just use plain text for the descriptions?

and out of the scope of this issue but for consistency reasons i've tried the same now for nodes (until now i did everything the other way around and checked if the behavior for custom blocks is consistent with nodes)

for node:

article: create new content - checked
basic page: create new content - checked
access the content overview page - checked
administer content types - checked

the rest of the node group permissions are unchecked. i have two nodes in /admin/content. there arent any operations shown like for custom blocks, thats the expected correct behavior.
but then a few potential problems. the content type column is empty, and the entries in the title column have the same problem like custom blocks, the title is shown as a link and when clicked i get an access denied. and if i click the add content button, even though the create new content permission is checked i get a You have not created any content types yet. Go to the content type creation page to add a new content type..

@rkoller

For the link to content feature. Sounds like this is covered by #3028906: Add access check when using "Output this field as a link" →

Maybe we open a ticket for when operations are empty to display something? Not sure if that happens in the view or listbuilder. But probably should be global fix.

@smustgrave i am not sure if i understand the linked issue correctly but if the effect would be, in case the user doesn't have the permission to view/edit content that the person gets an output like in the mockup, then it would be perfect imho.

i think access denied pages for options that are available to the user should tried to be avoided if possible.
but i wonder just one detail. wouldn't it be useful that there is a permission to allow viewing a block to users but not editing it? meaning a small group of people is responsible for the editorial part but then are those placing content and without the right to view/preview it might be potentially challenging to make a selection just based on a block description? ( i haven't read through the whole issue, perhaps that detail was already discussed before. )

and good idea about opening an issue for the empty operations column. but also that the content type column is empty seems odd, in particular since there are content types available for the nodes displayed. and as point, probably related with the empty content type, the you have not created any content types yet message when clicking add node might also need a ticket if there isnt any yet. but out of the scope for this issue definitely. just stumbled across them while comparing permissions for nodes and custom blocks.

Think the ability to view is it's own separate ticket also as we currently don't have that ability to view a block on it's own. Opened ✨ Add view tab + standard template for block content Needs work a few weeks ago that may address that.

ah excellent! i thought viewing a block was already discussed and decided against it. but if there is already a ticket for perfect!

I think it should get added as editors may want to preview the block without having to place on a page first. That ticket is about folding in a simple custom module. After the reorganization was going to add to my list.

Functionally I think this is ready, but we need a UX review.

Updated the issue summary to indicate the remaining tasks and the final state of the patch

Found 2 issues

1. When you have "access block library" and "Administer block type" permissions. On the block library the "Add custom block" button appears. It should not.

2. If you don't have "administer block type" permission then in the block library the type column is empty.

Pushed up a change for #211.2 still need to figure out .1

Maybe that makes sense? Because the link will take you to a page with a link to create block types. So you can create them just can't use them.

another scenario i've noticed: in the block section on the permissions page i have only Access block placement overview page checked the rest of the block section is unchecked for the role i test with.

• on the block layout page the operations column is empty which is correct, but the place block buttons are visible.
• i am able to click one of those buttons and the modal pops up.
• i am able to click the add custom block because the Create new block content permissions for the available block types are checked on the permissions page and i get to the new block content form.
• BUT back in the modal i am also able to click the place block button in the modals operations column. that click has no effect at all. i can click indefinitely.

=> in that case i wonder if it would make sense to hide the place block buttons on the block layout page in the first place?

and another detail on the block layouts page in the region column eventhough Configure existing block placements is unchecked on the permissions page i am able to alter the region via the select lists and move a block to a different region plus am able to save that change. without the permission also unexpected being able to alter the placement of an already added block.

Usability review

We've discussed this issue at 📌 Drupal Usability Meeting 2023-03-10 Fixed . The direct link to the recording of the meeting is https://youtu.be/af9KLbbo7MY

For the record, the attendees at today's usability meeting were @aaronmchale, @antoniya, @benjifisher, @rkoller, @shaal, and @simohell.

At first the group has taken a look at the patch from a functional perspective. We've visited the examples I’ve outlined in comment #1975064-198: Add more granular block permissions → (point 1) and #1975064-214: Add more granular block permissions → . I wanted to get some feedback wether the suggested changes find a broader agreement within the group.

There was a clear consensus that bugs in scope of blocks should be fixed within the issue while bugs that don’t apply to blocks only but to modules like media or nodes as well should best be solved for Core in general in a follow-up issue so this issue wouldn't be blocked. And there was the consensus and agreement if a permission is not granted for an interface component then that component shouldn't be shown to the user. that way no false expectations are created on the users end.

points only applying to blocks:

• if no create new block content permission is granted don’t show the add custom block button.
• if no block placement permission is granted don’t show the block placement buttons on the block layout page (even in case that the user has the permission to create custom blocks - having the modal just for the sake of the add custom block button and a list of custom blocks with dysfunctional place block buttons isn’t the best choice)

point applying to more modules in Core (at least for nodes):

• if not any operation related permissions are granted don’t show the empty operations column.
• if no permissions for viewing a node or custom block are available don’t show a link and just the title/block description instead.

Then it was noted that the issue is currently filed under the block_content.module component but the patch is applying changes to the block module as well. Therefore the group wondered if it wouldn’t be a reasonable step splitting up the patch - one for the changes to the block content module and one for the changes to the block module since each module also has different sub-system maintainers.

For the rest of the meeting the focus was on the micro copy for the permissions. After some discussion the group agreed that all recommendations that will be made will use the terminology in line with the current state and naming scheme in drupal instead of already using new terminology for this patch. Otherwise the patchwork of differently named thing would grow further and would make making everything consistent more troublesome in the end. It is the more sensible step to make all the necessary adjustments on the micro copy in 📌 Rename Custom Block terminology in the admin UI Fixed . Discussions can and should already happen in the linked issue but it makes sense to wait with the final renaming until everything is finally in place (the block permissions and the block layout in appearance).

The reason that lead to the aforementioned sticking to the currently used terminology for now, if you take a look at the section label custom block and compare it with the micro copy of the contained permissions, the term custom block could only be found in one out of nine permissions within the term custom block library.
Then there was the consensus to strike the word any since it is only used for the users own permissions (which are not available for custom blocks if you compare it for example with nodes). Then View any block content history pages was considered odd and confusing. Does that permission refers to the history module (probably not) so it is out of step with the rest of the revision related custom block permissions. Plus if you search for the string history pages on the permissions page it is the sole occurrence.
And in general we tried to be consistent and in line with the node permissions naming scheme. The suggested changes for the permission labels and two of it's descriptions in the custom block section are as follows:

We haven't had enough time to also finish the necessary discussion on the naming of the permissions in the block section. That requires some more discussion. We will revisit the issue finishing the review. Therefore i'll leave the Needs usability review on the issue.

Need to read a few more times but only concern with the label suggestions is we are trying to move away from "custom blocks"

@VladimirAus what changes did you make in the MR?

Removed the block specific changes to ✨ More granular permissions for block module Active

When testing the latest changes in the MR, I notice the permission labels still have the word "any" in them, which during the usability review we noted doesn't make sense unless there are corresponding "own" permissions.

I don't think "own" is going to work as the blocks don't have an author field so the blocks belong to everyone not the creator.

I don't think "own" is going to work as the blocks don't have an author field so the blocks belong to everyone not the creator.

Yep, that's what I'm saying :)

Just drop the word "any" from the permission labels in the UI, so %type_name: Edit any block content becomes %type_name: Edit block content. I would still leave any in the permission IDs/machine names, because that then doesn't hinder core or contribs ability to introduce "own" permissions in the future, if that's ever desirable.

We also recommended sticking with "custom block" in the permission labels just now, to be consistent with everywhere else in the UI, and then adjust the labels in 📌 Rename Custom Block terminology in the admin UI Fixed so that we're changing everything at once.

Dropped "any"

But not sure I'm for adding "custom block" knowing it's not correct and that we want to fix.

Maybe they should be called "block content" and "block content types" based on the core module's name? There are also views blocks and probably other types through contrib modules. If I recall correctly, there is a "block" and "block content" core module. Placing a "block content" or other types of blocks in a page's region is technically called a "block". It's probably not specific enough to just say "custom block" or "block", and might cause some confusion.

Let's use custom block in the user facing string, but block content in any machine names

Changing user facing string can be done in one go in the other issue

Yeah so the reason I'm suggesting doing the permission user-facing label changes from "custom block" to "block content"/"content block" in 📌 Rename Custom Block terminology in the admin UI Fixed is on the off chance it doesn't get done before 10.1, at least in 10.1 we have consistency throughout the UI.

Updated label.

Added comment to MR.

This is ready to go, fantastic work everyone.

I reviewed this from the perspective of a site that's making use of https://www.drupal.org/project/block_content_permissions → - good news is that that module should be obsolete now once this issue gets in.

The one permission block_content_permissions defines I wasn't sure on is view restricted block content "View full list on the Block Content overview page ignoring the create/update/delete filter.". However the new access block library introduced here and assigned to the block_content view covers that nicely.

I also think that using the user facing "custom block" doesn't feel right, however agreed that it is a good compromise. And it'll be fixed in the follow up 📌 Rename Custom Block terminology in the admin UI Fixed .

Also, fixed a minor CS issue with the @todo comment format.

In response to #234. I'm the project maintainer for the Block Content Permissions module. Good to hear this is almost done. My module is temporary until this works.

Regarding the "View restricted block content" permission. It relates to an extra feature I added for practical reasons outside the scope of this project. Drupals default behavior is to show all or nothing. I felt seeing all block content in the library list regardless of permissions could be overwhelming, so by default I restrict the list to those the user can create, edit, or delete. Enabling that permission turns off that restriction so you see the full list, which is the default Drupal behavior.

Saving issue credits

Un-postponed 📌 Make use of new block content permissions in Umami profile Active
Published change notice
Added to release notes

Committed and pushed to 10.1.x 🎉

Huge effort everyone. 10.1.x is shaping up to be the block content release 🥳

Thank you to all of those who made this happen!

I also tested it and it works great. Thanks everyone! I've added info to the Block Content Permissions → module for migrating to the new permissions.

Added follow up for some help text we missed here 🐛 Hook help for block content module is out of date after new permissions Needs work

Tagging for release notes and release highlights. Great work here!

Great to see this land, thanks everyone!

See you all in the other issues on 🌱 [meta] Reorganize Block items in the administration menu Active .

This issue is tagged for, 'Needs usability review', but I see that happened in #47 and #215 but the tag was deliberately not removed in #215. Now that this is fixed, is it still needed?

I asked that in #ux and @AaronMcHale confirmed that the tag can be removed.

Yep! Can confirm that the usability group was very much involved in this issue and the tag not being removed was simply an oversight.

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

Block permissions that were working in D9 don't seem to be working anymore in D10.

In drupal 9 our editors had the following content block permissions:

Type 1: Edit content block
Type 2: Edit content block
Type 3: Edit content block

With these permissions we were able to build an admin listing of content blocks (using views) that contained the "Bulk operations" field. Editors could use the edit link here to edit these Blocks. Important note: This view's Access is set to Permission: Type 1: Edit content block

After upgrading to Drupal 10, editors can still access this view (so the permission works in general), but all the edit links are missing from the "Bulk operations" column (so the permissions do not work for editing blocks anymore)

For developers (admin role) both edit and delete links are present under "Operations".

What I tried:
* Does not work: Adding the views field for "Link to edit Content block" -- this link appears for developers (admin role) but not for editors.
* Does not work: Adding the views field for "Block content ID" and rewriting this field as a link /admin/content/block/{{ id }} -- this link appears for editors, but when attempting to edit the block they still get "Access denied"
* Does work (with consequences): Granting editors the Administer block content permission -- this restores the edit links for editors, but it also adds a delete link, and grants them edit/delete access to additional block types that they should not be able to access.