Multi-entity permission management

[adamziel]

What problem does this address?

In the multi-entity editing world, a low-permission user may edit a post that contains high-permission entities like Navigation (see the report by @spacedmonkey, and @getdave's PR with a navigation-specific fix: #37454).

Let's find a way of dealing with permissions in the multi-entity world.

One way to approach it would be to address these use-cases:

• Freezing parts of the blocks that represent the entities the user has no permissions to edit (@talldan mentioned templateLock could be a fit)
• Communicating that the user only has access to edit specific parts of the post (or site)
• Excluding the non-editable entities from the Publish panel
• (ideally) Allow editing an "allowed" entity nested inside a "not allowed" entity

There may be other ways to proceed, too. This issue is about the overarching theme, not any particular solution.

Here are a few specific reports of this problem:

• As a contributor / author navigation block only shows a spinner #36286
• Page List block infinite spinner if user has insufficient permissions to access Pages #37368

Potentially related issues:

• Site Editing: Restrict block editing capabilities based on editing context #27848
• Site Editing: Allow template edits to be saved as a new template #27851
• UX for saving reusable blocks as a contributor who has no permissions

cc @youknowriad @mcsf @mkaz @jorgefilipecosta @draganescu @talldan @mtias @noisysocks @ellatrix @ntsekouras

[getdave]

Thanks for raising. My notes about the problems in getEntityRecord and getEntityRecords in #37368 are particularly noteworthy it basically means many entities are not readable by lower permission users (due to edit_posts requirement) despite them having the read capability.

[youknowriad]

I've discussed this with @getdave a bit as well, can we try switching the loadEntities calls to view context and see the impact?

[getdave]

an we try switching the loadEntities calls to view context and see the impact?

I gave that a try but even within the limited scope of the Nav block there seem to be several knock on effects. Data missing on responses...etc.

That said, a PR exploring that in more detail would be helpful in order that we can all assess the impact together 👍

[mcsf]

high-permission entities like Navigation […]. Let's add a generic way of dealing with permissions in the multi-entity world. The specific use-cases to address include […]

Navigation is a particularly complex block, and seeking to generalise a solution from a sample set of one seems premature. Shouldn't we first use Navigation as the stage for finding the best user experience for dealing with these many-to-many user-cap relationships with the specificities of that block in mind — and only then consider generalisations?

[adamziel]

@mcsf I think exploring different solutions through the navigation block is a great way to proceed. This issue doesn't prescribe any particular prioritization, it merely highlights a problem that every entity-related block (like Page List) must consider in some way. I updated the wording to make the intention clearer.

[spacedmonkey]

One of the issues, is related different between being able view and edit a entities.

In core data, a request to wp/v2/types is made. This request is made with context=edit param.

gutenberg/packages/core-data/src/entities.js

Line 208 in 812fa1b

const postTypes = await apiFetch( { path: '/wp/v2/types?context=edit' } );

This means that only entries / post types that a user can edit can be listed. However, for menus/navigation post types, we want to be view and not edit these posts. Core data should not always guess a user can edit a post. All request to post type endpoints, also default to context: edit.

gutenberg/packages/core-data/src/entities.js

Line 217 in 812fa1b

baseURLParams: { context: 'edit' },

We should add a new field to the wp/v2/types endpoint, called default_context. Then the rest api can be change context field depending on if the user can edit or view the post type.

Willing to work on the php change and it will be relatively simple.

[megphillips91]

Adding a use case

In the case of a WooCommerce store, Imagine I am a SAAS provider who builds pre-configured stores for merchants. The most convenient way to manage the parts and template parts that my internal designers can manage vs. the merchants at my clients is to simply provide only the 'store manager' capabilities...but I don't want to wall off ALL site editor functions from the merchants - not by a long shot.

• imagine a future where each part of the single product template is an individual block: add to cart button, product title, product short descriptions, etc.

I would never ever want to wall off the possibility for merchants to create their own single product templates or product category landing pages. For a store builder, this will provide business impacting freedom to merchants and I'm super jazzed for this to become reality and train merchants how to do that, right? Like heaven on earth for an internet merchandiser!

But wait

In the scenario I outlined above, within the normal course of business a merchant could accidentally foul up the header, footer, or checkout pages. Make giant mistakes which could essentially 'break' the entire store, change the navigation, totally change the information architecture, unintentionally send big signals to search engines. Merchants rely on store builders by to protect them from these unintentional mishaps.

Store builders need granular control.

Here are a couple examples that I'd like to consider.

• editing templates but no capability to edit certain template parts? (ex: navigation parts)
• editing others templates/template parts vs. editing my own templates/template parts

[talldan]

It's also worth considering the reusable block, which is a much older block and surprisingly seems to have no handling of permissions. A contributor can edit the content, but gets an unhelpful 'Saving failed' error when trying to save.

It'd be good to make sure it's not forgotten 😄