Have the ability to specify read/write permissions on the field level

[cj]

Hi,

It would be great to have the ability to specify read/write permissions on the field level. That way someone can’t see all your models fields by simply looking at the schema; plus it would be really nice to have private fields that only x roles can see, it would open up the possibilities even more with DATOcms!

[thimovss]

For our use case we require to be able to specify CRUD permissions on field level. Some fields shouldn’t be visible for certain roles, some roles can see certain fields but not edit them, etc. So we either require to able to assign CRUD permissions based on roles, or be able to create different views for different roles. Are there plans to put this issue on the roadmap?/ What is the status of this issue?

[Souljuse]

Linked to:

Possibility to prevent field editing depending on permissions

It would be great to have an option to hide slug fields from editors. For most sites, my editors have no need to manually edit model slug fields, they can be generated from article titles or category names automatically. I can generate slugs from titles/names on the client site of course outside of Dato, but aside from adding more client code, the nature of the GraphqQL query API often means a lot of duplicate data (which is fine, you can use fragments and so on). This means decorating the inco…

[roger]

This would be great to have!

For now, I’m just adding a “for developers only” fieldset and putting all the dangerous fields in there. There is also a Hidden Field plugin… maybe that can be extended to check user role/permissions before showing the field?

[mat_jack1]

Yes, the “Hide field from role” plugin normally does the job: Hide field from role - Plugins - DatoCMS

Let us know if the plugins are not enough!

[roger]

That should be fine, thank you for the suggestion!

It’s not the safest system (anybody who knows how to edit CSS can un-hide that and change the value), but on our small & trusted team it’s probably not an issue.

[mat_jack1]

I completely agree, it’s just a workaround, but before adding a lot of complexity there we are trying to understand if that’s the only use case

[roger]

One use case is to facilitate multi-role editor environments. For example one person might draft the initial article, another person might fill out the SEO fields, a dev might add some arbitrary JSON into a secret field, and then a reviewer would review & publish all of it.

Or, another use case is that maybe we don’t want the slug (or some other unique ID) to be changeable after creation by anyone except devs & admins (not sure if that’s possible… i.e. if there’s a difference between a model entry creation vs field update).

But the workaround should suffice for now. Thanks!

[mat_jack1]

yes, with the plugin you should be able to hide the fields from the specific roles.

Regarding the ability of hiding a field after the creation you might be able to implement that with a plugin!

[joren]

I’d like to be able to allow a role to edit only certain fields. For example, an SEO manager could be allowed access to just the metadata field.

[joren]

I’d like to be able to allow a role to edit only certain fields. For example, an SEO manager could be allowed access to just the metadata field.

[bernie]

This would be very useful for me too. My use case is that some of my models have a system identifier string used as a unique identifier by the app to locate a bit of content. Content editors should be able to edit records, but not change the id which would break the app.

Ideally it would be possible to apply this to individual fields on blocks as well as on models.

[m.finamor]

Hello @bernie and welcome to the community!

For this case you could probably just disable the field for editing with this plugin:

This way the field can only be edited through the API Disabled Field - Plugins — DatoCMS

[bernie]

Legend! That’s exactly what I was looking for thanks

[tobias.maier]

@m.finamor Have there been any changes regarding field level permissions?

[roger]

Sorry @tobias.maier , not yet The best workaround so far is still to use a plugin to fetch the current user’s role and then disabling editing in the UI. Sorry about that!