Ah that's a misleading label then yeah. Readonly is intended to make the field readonly in the app in all cases. It's not intended to be a 'only allow value to be set on creation'

Any thoughts on a better label? MDN's description for readonly is very similar "The Boolean readonly attribute, when present, makes the element not mutable, meaning the user can not edit the control."

I see. That raises multiple questions for me:

• If it is intended to be read-only in all cases, why can I set value via API? Is that a bug?
• How would I be able to set the value through the UI in case I declare the field as read-only? Is that even possible?
• How can I achieve the behavior of being able to not modify a value after creation (so read-only for editing, but when creating the item I can define a value)?

Regarding the naming for the label, I think mentioning "immutable" in the description might be a step in the right direction. Additionally, mentioning the behavior in the documentation, e.g. when discussing fields (https://docs.directus.io/app/data-model/fields.html) might help users to know what this option does.

Interesting.

• I think Readonly is the right term for how this works (can not create or edit), but agree we should update the docs, fix the API loophole, and look into adding a field note to clarify the setting.
• You should be able to use access control to set who can create or edit a field's values more granularly
• We could look into making readonly a more flexible field-level setting, that has options for specifically disabling entry on create versus edit.
• We could show a warning notice when both of these options (readonly and required) are enabled... to warn of this potential trap.

Maybe the term "editing" in the label "Disable editing value" lead me astray and my mind was fixed on "editing" as in "modifying after creation". In my opinion this "edit" term is slightly ambiguous.

Either way, I would be happy with the API bugfix and clarification in the documentation.

• being able to not modify a value after creation (so read-only for editing, but when creating the item I can define a value)

This would be a practical option.
Do we currently have any way to achieve this?

• being able to not modify a value after creation (so read-only for editing, but when creating the item I can define a value)

This would be a practical option. Do we currently have any way to achieve this?

If I am not mistaken is the only way through a custom extension (filter hook for item.update events or more specific for a certain collection) that checks if a specific field is part of the payload and reject if that is the case. You could implement this with a flow as well. Either way, this approach is only a viable solution for specific collections. Having a generic approach would make that custom extension more complex as the meta information (which field is read-only on edit only) needs to be implemented as well.

If you ask me, I don't see why the field shouldn't be editable via the API. It has to be editable somehow otherwise the field would be useless and making it only editable during creation is limiting I think. As said above, access control should be sufficient for defining who can create or update the field and under what conditions.

IMO, simply updating the label to specify that readonly here means "in app" should suffice - that way it serves more as a visual UI cue which is what it's most useful for.

+1 for "Disabled for UI editing" will be great option.

I want to have some fields open for API but not for GUI - like "slug" which i want to alter via API, or via creation, or via custom extension, but not from UI itself.

Note: Read-only values can be set on creation by its own default value?