More granular permissions for block module

Created on 13 March 2023, over 1 year ago
Updated 1 February 2024, 10 months ago

Problem/Motivation

From Add more granular block content permissions Fixed moving the block permissions to this ticket

Steps to reproduce

NA

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

Feature request
Status

Active

Version

11.0 🔥

Component
Block 

Last updated 4 days ago

Created by

🇺🇸United States smustgrave

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Issue created by @smustgrave
  • 🇩🇪Germany rkoller Nürnberg, Germany

    Usability review

    We discussed this issue at 📌 Drupal Usability Meeting 2023-03-24 Needs work . The link to the recording is: https://youtu.be/qJwNgsk-7bg

    For the record, the attendees at the usability meeting were @aaronmchale, @benjifisher, @ckrina, @rkoller, @simohell, and @smustgrave.

    I am currently trying to get some of the still open usability meeting issues fixed. This issue is long overdue and idling for a few months now since we forgot to comment on the issue. I've rewatched the part of the recording relevant to this issue now and did some additional testing since many of the block related changes that were a work in progress back then are in Core now. A brief summary:

    First it was pointed out to exercise caution and being mindful about the potential permission related implications moving the Block layout page. The plan back then before getting postponed was moving it to the Appearance page. For that given example a user would need the permissions not only for accessing the Block Layout page but also for the Appearance page.

    All proposed permissions for this issue are related to the Block layout page. The list back then was:

    • access block placement overview page
    • administer blocks
    • configure existing block placements
    • create new block placements
    • enable /disable blocks
    • remove blocks

    Before going into more detail or start any word smithing discussion the group took one step back and questioned if that degree of granularity is actually necessary at all for the Block Layout page?

    Instead of introducing new permissions to turn certain functionality on and off for a role on the Block Layout page @aaronmchale brought up the perspective as someone working at the university of Edinburgh. They have lots and lots of editors and lots of sites. Even with that many editors and sites he struggles to see why you might need that many new permissions. From his perspective, there is no real use case for anything more than getting access to the Block layout page.
    Instead it would be preferable to get the ability to granularly limit which regions you can place blocks in and what blocks you are able to place in those regions. For example, you as a site owner, without full administrativ privileges, can place some blocks into the main content area but all other regions are locker for you and the blocks you are able to place within that main content area are limited to only certain block types/blocks.

    In the end the group came to no clear consensus and the discussion was cut at one point. It was agreed if someone really thinks that there is the need for all of these new permission that person should make an argument for it on this issue. And looking at the issue summary the sole motivation was to simply copying things over from the parent issue. We should ask ourselves what problem we are trying to solve here and why we need all of these new permissions.

  • 🇩🇪Germany rkoller Nürnberg, Germany

    Back then I was the person voting for adding these proposed granular permissions, but I have to admit revisiting the issue, that I was wrong. My vote was mainly driven by the desire of keeping the admin/site builder in control and provide more flexibility configuration wise. But rewatching the discussion and given the closing words "We should ask ourselves what problem we are trying to solve here and why we need all of these permissions" on second thought I am also voting against adding more granular permissions.

    The one thing that should be considered is rewording Administer blocks and maybe also adding a description to provide some context what the permission entails. At the moment Administer blocks is too abstract and in particular doesn't any indication that one of the main abilities is to view and use the Block layout page to its full extent.

    Another detail, If you try to make a clear separation between blocks, content blocks and inline blocks there are a few examples i've tried that might cause some headscratching:

    1) all permissions deactivated under block content, administer blocks active, then you are still able to see and place a content block on the block layout page but you are unable to edit it.

    2.) all permissions deactivated under block and block content. only access the content overview page and administer content under node and everything for layout builder is active. and i've activated layout builder on the article content type as well and set layout builder active on a per node basis. i then went into an existing node and went into layout builder. i was able to see and add blocks and content block as well as create inline blocks (called "create content block" as well there .

    technically everything is more or less correct but (imprecise micro copy aside) if the user doesnt know the underlaying technical concepts that behavior is more than difficult to understand.

    In regards of Aarons suggestion I am not entirely sure if it is the right thing to manage the configuration into which regions a user can add blocks as well as which kind block can be added to a region completely via permissions. It might work but maybe a dedicated config page would be worth a thought in combination as well?

Production build 0.71.5 2024