Feature request: read-only / non-editable input field attribute (XP8 / Content Studio 6)

Features
1

As a developer, I want to mark a specific form item in a content type (or mixin) as read-only, so that editors can see the value in Content Studio but cannot change it.

Use case

We have fields whose values are set programmatically, e.g. populated by an import job, a scheduled task, or derived from another system and should never be edited by hand in Content Studio. Today editors can see these fields and freely overwrite them, which breaks the data or gets silently undone on the next sync. We still want the value visible in the form (for context), just not editable.

Current situation (XP8)

As far as I can tell there’s no supported way to do this at form-item level:

  • Looking at the form-item reference (e.g. TextLine), the available options are things like default, max-length, show-counter and regexp — there’s no read-only / disabled flag.
  • Permissions are item-level, not field-level, so they can’t lock a single field while leaving the rest of the content editable.

Proposed feature

A simple boolean option on the form item, fitting the existing YAML structure, e.g.:

form:
  - type: "TextLine"
    name: "externalId"
    read-only: true

The field would render in a disabled/read-only state in Content Studio visible but not editable similar to how the published Path field locks, rather than hiding the field entirely.

2

Hi Egil,

We have stopped completely mixing 3rd party content with editorial content from XP on our projects. The “human error factor” is too great. And it can be difficult for some people to understand what is the source-of-truth

Instead we use repo-lib and node-lib to create a copy of the 3rd party content in a repo. And then use a custom selector to create a reference between the editorial content and the 3rd party content.

Good luck!

– Tom

3

The use-case is real for many scenarios, and the new content.patch simplifies programatically updating content as well.

This feature request has existed for a while, and it has even been written a specification.

The solution is what we call “managed” fields. Basically, the behavior is what Egil asks for (disabled, but visible in UI). However, it is fully writable from an API perspective. Additionally, the idea is that named roles may even unlock and edit the fields from UI.

So, feature is approved - but ETA is not set yet.