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!
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?
Linked to:
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?
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!
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.
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
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!
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!
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.
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.
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.
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
Legend! That’s exactly what I was looking for thanks 
@m.finamor Have there been any changes regarding field level permissions?
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!
Our client has their Content and Product information all hosted in DatoCMS as a single source of truth, and for their business, this is the holy grail—having everything centralized.
For internal use (websites, commerce, intranets, etc.), it works perfectly. However, now they want to go to the next level and offer their Product Information to third-party providers like marketplaces and distributor companies. They want to provide access to read a few content types, which can be done internally in DatoCMS with roles and permissions. The issue is controlling field-level access because I cannot manage that level of granularity. If I give read permissions, for example, to the “products” content type and the linked “people” content type, the third-party provider could query and list not only all the “products” but also all the “people,” even if they are unrelated to products. This poses a security and safety risk that my client does not want.
Therefore, we were considering using a middleman application like Apollo GraphQL with GraphOS or Hasura to manage field-level control and queries. However, this requires your GraphQL API to support such features. Otherwise, we would need to build a wrapper app to map the API and then connect it to Apollo, which is not our goal.
Currently, our only workaround is to custom-build our own app to manage the API and implement this control, but that is not aligned with our business goals or needs.