Read Only attribute inside Geodatabase

[AdamForknall]

It would be nice to be able to set certain feature datasets, feature classes, tables or rasters inse a Geodatabase as Read Only to prevent modification, without the need for using an enterprise GDB/arcSDE with user permissions etc. Just a local implementation, similar to the Read Only and Hidden attributes which can be set on a file within Windows.

[DuncanHornby]

For what it's worth you can make a field read only when the dataset is loaded into ArcMap by going to the layer properties > field tab.  So if you supply your datasets to others as layerfiles they won't be able to edit those fields. Bit of a fudge...

[MarkVolz]

Duncan,

I agree that it is useful that we can set read only within ArcMAP.  However, I think this would be an important addition to the dataset itself as people often use the same data within multiple projects. 

ESRI,

This feature would be useful to flag fields that derived from other fields such as a concatenation of other fields.  I don't know what forknuts original intention was for this idea, but I imagine it could be used so fields could only be changed by geoprocessing scripts or the attribute assistant.

In addition, I think it would be useful to add "visible by default" and "highlight by default" as well.

Thanks

[Bud]

Merged from a separate idea.

If I understand correctly, it's possible to set a field as read-only in the map Contents layer properties.

But it's not possible to set a field as read-only in the feature class source properties in the geodatabase.

It would be helpful if we could set fields to read-only right in the FC source.

I'm aware that we can do something similar using attribute rules. But that requires custom code, adding complexity to an already heavily customized system. To me, it would be better if we could do it using OOTB functionality in the FC source properties.

ArcGIS Pro 3.0.3

[MarceloMarques]

@AdamForknall - this can be achieved directly in the rdbms by creating an editor user or viewer user that has restricted privileges to the data owner tables (e.g. featureclasses, tables, gdb versioning, gdb archiving, gdb network, etc.).

• Database Connections Best Practices

For more information on how to create an editor / viewer user read my database guide books for Production Mapping, see link below.

Mapping and Charting Solutions (MCS) Enterprise Da... - Esri Community

[Shaun2-Zag]

How would that work for Branch Versioned Feature services where the connected geodatabase user   must be the owner of the data [when sharing/publishing with versioning enabled]? publish-branch-versioned-data.htm 
i.e. I don't believe you could use different geodatabase editor user(s) with varying database permissions as the feature service [published] geodatabase user has to be data owner.
e.g. Editor user 1 can modify field1, field2 but field3 must be read-only.
        Editor user 2 can modify field3, but field1 and field2 must be read-only.

[MarceloMarques]

Indeed, the editor and viewer users will only work for traditional versioning to restrict privileges to only certain tables of the data owner user. Column level permissions in only available in Oracle. Example: "grant update (col1, col2) on mytab to editor1;" and SQL Server and PostgreSQL do not have this feature.

If you are using branch versioning, then the feature services must be published as the data owner user. If you are the data owner user then you will have read-write privileges on all tables and all columns, cannot be granular here, the only way is to set some level of permissions via the application itself, like read-only fields in the map document layer properties, unfortunately cannot set this at the geodatabase properties level, this feature does not exist in the enterprise geodatabase. It would be a nice enhancement. Once the branch version feature service is published then you can control the level of access to the service using the user's portal login, the user will need to login into portal to use the branch version service for editing.