Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Core Data: Add entity prop locking and use it in the Site Title block. #18772
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.
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
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
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
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
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
Think about cases where a prop may be locked for different reasons in different circumstances and this doesn't map directly to things like
@mtias also has more thoughts on this.