Core Data: Add entity prop locking and use it in the Site Title block.

[epiqueras]

Description

This PR addresses a need found by #18760 and is an alternative to it.

Certain entity props, like a site's title, should not always be editable depending on editing context and/or user permissions. The framework should provide a declarative way of "locking" these props.

This PR provides a way to define default "locked" values for different entity types in their configs, and a way to track and edit these values on a per-entity-record basis. The "locked" values can either be literals that will be wrapped in getters, i.e. true, becomes () => true and means a prop is locked, false or undefined means it's not, or they can be functions that will be pre-bound to select.

This approach allows for simplicity and the flexibility for consumers to derive the values based on any state, like the site entity config does in this PR with canUser.

Additionally, useEntityProp's setter now throws a warning when trying to set a value for a locked prop, and it also returns a third variable, the evaluated "locked" value for the specified prop. This made the changes needed in the Site Title block minimal and it made it really easy to avoid forking the rendering path when the site title is locked.

How has this been tested?

It was verified that using the Site Title block logged in as a contributor renders it disabled.

Types of Changes

New Feature: core-data entities now support locked entity props for managing props that shouldn't be editable under certain context and/or with certain user permission levels.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR. .

[youknowriad]

Not sure I understand why we need the ability to lock properties, for me this is more a value that comes built-in depending on the role of the logged-in user instead of something you should/can set.

[epiqueras]

Locking will be necessary in situations outside of user permissions/authentication (think Newspack blocks) and even the way we query user permissions can vary enough that we benefit from making this general in the framework.

Compare the changes to SiteTitleEdit in this PR vs. #18760. Locking leads to much more maintainable block authoring.

[youknowriad]

I'm still not convinced here to be honest. It's not about the consuming API itself which I'm fine with but it's just a duplicate of canUser.

It's more about the responsibilities. I don't think locked properties should be defined in the entity config as they can change per user, we should just consume them from the existing Rest APIs and I don't think a public setLockedEntityProps action make sense.

[epiqueras]

I don't think locked properties should be defined in the entity config as they can change per user, we should just consume them from the existing Rest APIs and I don't think a public setLockedEntityProps action make sense.

Think about cases where a prop may be locked for different reasons in different circumstances and this doesn't map directly to things like canUser. What if, for example, a user can edit a post's title, but you want to lock it when you switch to a certain editor mode. This could certainly be done at the block level, but what if there are multiple blocks that edit the same prop? This would avoid that code duplication.

@mtias also has more thoughts on this.

[mcsf]

What if, for example, a user can edit a post's title, but you want to lock it when you switch to a certain editor mode.

I wonder, then, if this is the right tool for the job. We might want to take a broader look at what "modes" could be and how core and third parties would implement them. Otherwise we may be conflating concerns between pure permissions and user-activated restrictions.

For instance, my initial impression is that an API like setLockedEntityProps might be too imperative if the goal is to declare modes.

[epiqueras]

Let's close this PR for the reasons you stated.

#18956 paves a better way forward by generalizing canUser. We can extend it to support things like:

canUser( 'update', 'postType', 'post', 123, 'title' )

And keep all the permissions logic coherent.

It might require some extensions to the API. Still, this way, we can keep the permissions logic in the server where the data is. setLockedEntityProps was just an imperative way to lock things when the client could confidently assume that certain properties were not allowed to be updated by the server.