Blocks relying on entities are broken (Categories, Tags) for contributor roles

[youknowriad]

We know due to REST API/data module issues that calling getEntityRecords is not allowed for Contributor roles for certain entities.

It seems like some blocks are doing this though. Tag Cloud and Categories blocks don't work properly for Contributor role.

We might have other blocks suffering from the same issue as well. Nav block is tracked here #18659.

--

Ideally, we could have linting rules preventing this or we should solve the underlying issue (find a way to use these selectors for all users) cc @aduth

Related #11643

[aduth]

To some extent, blocks should need to be aware of necessary permissions, either for the block to be available at all, or for certain features of the block.

Is the Navigation block one which can't really exist at all for a user without permissions to manage site options? I can't recall if we'd discussed it previously, but I wonder if there might be some need to manage the availability of a block dependent on a required capability (perhaps as part of the block registration itself).

Some others may be case-by-case permissions issues where either we're providing an edit context for a REST API request, which is in-turn enforced at a higher capability. If it's information which should be more readily accessible, we can consider reaching out to the REST API team to see if some data can be switched to different contexts.

I'm not sure how we can make the selectors "work" if the user doesn't have the correct permissions. Then again, I'm not clear on what's currently happening. There should ideally be some graceful fallback, but I'd be worried if this graceful fallback might lead to some misinterpretation (e.g. returning an empty array when the user has no capability could falsely imply the absence of data).

I'm open to ideas on linting rules, though I'm not sure how you imagine that to work. Perhaps we map specific selectors to a warning that flags it requires a certain capability, and then the developer disables the rule to acknowledge that they've taken appropriate steps to accommodate? (similar to some of the accessibility rules we disable)

[youknowriad]

• My ideal solution is still this https://core.trac.wordpress.org/ticket/45252
• Having a new context or no context, that means, "all fields a user can access to" and switch the data module to use this new context.

I'm not sure how Realistic would it be to get support from the REST API team on this.

[Mamaduka]

I think we can close this one after ##32961 and follow-up PRs.