Allow authors and editors to edit page layouts in Umami

I'll test it!

@gxleano:

Thanks for helping with this issue.

Whether or not the testing goes as expected, please give details about how you tested. A few screenshots would help: show the URL and the logged-in user, and perhaps the confirmation message after making changes.

Tested in version 9.2.1-dev, which is the branch the merge request is created against.

TEST RESULT (Step by step)

1. As an Admin user, go to /admin/people/permissions and check Layout builder permissions for Author and Editor roles.

The permissions below are automatically enabled to the Author and Editor roles:

• Content - Article: Configure layout overrides for content items that the user can edit.
• Content - Basic page: Configure layout overrides for content items that the user can edit.
• Content - Recipe: Configure layout overrides for content items that the user can edit.
• Create and edit custom blocks.

2. As an Admin user, go to /admin/structure/types/manage/article/display and enable "Use Layout Builder" option over Layout options.

3. As an Author and Editor user, try to edit the layout of his/him/their existing content (Article, Recipe or Basic Page).

Edited Layout of content /node/11/edit?destination=/en/admin/content, adding a Basic block (custom block) and everything is working as expected.

To sum up, the code into the MRs looks good to me, and it's working as expected.

@gxleano:

Thanks for the testing. Your Comment #16 is just what I had in mind.

Since 9.2.x is not even supported anymore, this issue should really target 10.1.x. The core committers may decide to back-port it to 10.0.x and 9.5.x since it is not a disruptive change. (It affects only new installations of the Umami demo profile.)

I checked, and the patch (or diff) from the merge request applies cleanly to the 10.1.x branch.

I also noticed that, after applying the patch, the permissions are not in alphabetical order. I am sorry I missed that in #9. I am setting the status back to NW for that. I think that fixing the order is a Novice task, so I am leaving that issue tag. I am removing the tag for manual testing. After #16, I do not think we have to re-test.

I've created a merge request to 10.1.x adding the permissions ordered alphabetically.

It looks like CI is failing for the MR.

  array (
    0 => '    - core.entity_view_display.node.article.full',
    1 => '    - core.entity_view_display.node.page.full',
    2 => '    - core.entity_view_display.node.recipe.full',
  ),

These are dependencies that are missing in the role config. Permissions now have dependencies ( https://www.drupal.org/node/3055548 → ) and so giving a role a permission for a node type means the role config entity has a dependency on the node type config entity.

(Aside: AssertConfigTrait::assertConfigDiff() should be converted to a PHPUnit custom assertion, and uuuuurgh the Drupal\Component\Diff component has no documentation!!!!)

I've fixed the Demo Umami test, but now it seems to be unstable with FunctionalJavascript test in CKEditor 5.

LGTM!

Updating title, and saving issue credit.

Backported to 10.0.x/9.5.x as a low risk bug fix; the config change only affects newly installed demo sites.

Committed and pushed f0269a4896 to 10.1.x and 6f2b88b8dc to 10.0.x and 3d51469370 to 9.5.x. Thanks!

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