Feature request: Option to disable input field in content-types in Content Studio

When building integrations with external data sources, we often store external IDs in content nodes created by the integration (for instance crmId). Having the value visible in Content Studio is helpfull, but in a lot of cases, we would like to disable the option to edit this field when editing the node.

Example input in content type:

<input name="crmId" type="TextLine" disabled="true">
      <label>CRM ID</label>
</input>

Where the parameter disabled=“true” would make the field visible in Content Studio, but not editable.
Or it could be a different type, where we could set what the input should be displayed as:

<input name="crmId" type="Managed" display="ContentSelector">
      <label>CRM ID</label>
</input>

Where the “Managed” type would mean it could not be edited, and the display parameter determines how Content Studio should display the value.

These values still needs to be set/changed by “su”, which usually is the user context we use when creating, updating or deleting nodes in integrations.

Feel free to give your thoughts or comments on the proposed feature.

4 Likes

This is an often requested feature which has been in our Roadmap for some time (see here and here).

The reason why it’s taking a while to implement is that we want it to cover all possible requirements. Some want to be able to hide some inputs completely, some want to always show them as readonly, some (like you) want to disable them only for specific roles (for example, disable for Content Editors but enable for Content Managers or Admins).

We will definitely look at this in the nearest future.

1 Like

Thanks for the reply. We have ways to solve this outside of Content Studio now (with event listeners), but from a user perspective its best to get it in CS, so they can see that a field is disabled/locked.

Hi. We have researched this topic, and come up with a solution where you will be able to specify read/write permissions on a per input and role basis. This will enable high flexibility, and for your use-case you could simply deny both read and write for your users as required. this will also be reflected in the APIs.

No ETA yet.

1 Like

Hi,
I just discovered this thread, which seems quite spot on a use case I’m currently working on.
Has there been any progress on this feature?

1 Like

Hi. The feature is spec’ed, but sadly we have not had the time to start implementing it yet :pensive:

I see, thanks for feedback.
My idea was to be able to hide/disable certain inputs based on the logged in user’s role, so I thought this topic could be fit for that. Are you aware of any other ways we could handle that?

This is basically what this task will do, there are no viable workarounds to this ATM, at least if you want to be able to edit these fields from Content Stduio