Problem
Field definitions and typed data definitions have an isReadOnly() method. However, right now isReadOnly() is not taken into account anywhere, e.g. for validation or access checking (as discussed at #2099259: Missing default access for all taxonomy term fields).
Proposed resolution
Discuss options, decide which one to use, document and apply it.
Remaining tasks
See above.
User interface changes
-
API changes
tbd
Comments
Comment #1
fagoRight now, for nodes read-only is set on node nid, uuid, vid and type. However, uuid and type fields should be settable during creating, while nid, vid and more read-only fields like changed, revision-timestamp which shouldn't be settable during creation - unless for migrate use-cases.
So we've got two flavours of read-only fields:
Then, it probably depends on the storage whether a read-only field is still writable by migrate. I'm not sure it's necessary to cover that difference in the metadata as migrate already does fine without it.
In order to apply the read-only flag we could:
- disallow 'edit' for read-only fields
- validate read-only fields are not changed, i.e. compare its value to the original entity on update
- validate read-only fields are never set, i.e. in addition to verifying that they are not changed we could make sure there is no value for them when validating a new entity.
The first two points make sense for both variants a) and b), the third one does only for group b).
So the main question left here is: How do we handle fields that are settable during creation like uuid and type?
Variant A: We differentiate and mark them as "create+ready only"
Variant B: Mark them as read-only as well and make real read-only fields have an additional constraint? We could have a read-only validation constraint which has an option to allow setting during create. Then, those ready-only fields could override the default constraint by setting it that way.
Comment #2
heddnTagging
Comment #4
larowlanI think UUID should be settable on unsaved entities, not necessarily through creation.
I.e $entity->isNew() === TRUE is same as through ::create
Comment #6
Berdir#2824851: EntityResource::patch() makes an incorrect assumption about entity keys, hence results in incorrect behavior solves a part of this, by adding generic access logic for this.
Comment #7
Wim LeersComment #8
cilefen CreditAttribution: cilefen commentedComment #11
Wim Leers#2824851: EntityResource::patch() makes an incorrect assumption about entity keys, hence results in incorrect behavior just landed.
Comment #14
Wim LeersPer #6, #7 and #11, tagging
#2907629: Read-only behaviour of data definitions is not clear is related too, thanks chx for pointing there!