Allow privledges to be set for feature classes within a feature dataset

[RobertDeHerrera]

In a multi-user SDE environment, some feature classes need to participate within a topology. However, we need the ability to deny edit privledges to selected feature classes within a feature dataset. An example:

• Tax district boundaries are maintained by the Assessor's office.
• Election precinct boundaries are maintained by the Elections office.
• Both tax districts and precincts share topological relationships.
• Elections staff don't want Assessor's staff fiddling with their boundaries accidentally.
• Assessor's staff don't want Elections staff fiddling with parcels accidentally.

Currently, the only option in SDE is to grant users from both offices full edit permissions to the entire feature dataset.
We need the option to disallow edit privledges to individual feature classes within a feature dataset.

[CattyannCampbell]

Absolutely! We run into this in my office all the time in our case it has to do with Easements and Zoning boundaries.

[MicahWilliamson]

 yes, This is a good idea. My workaround is that I push a copy of the needed feature class out to another department after topology is run, creating redundant data. 

If they do this ArcCatalog would need a better way to 'track' privileges. 

[JoshuaDye4]

I have run into similar problems inside one of our datasets. I would love to be able to add that extra layer of protection to feature classes. I have "fixed" more than once, an edit session gone wrong.

[GIS-Cambria]

I agree with permissions at the feature class level, regardless of participation in a dataset or not.

As a workaround for now, couldn't you set up department specific GDBs and replicate pertinant info between departments. Then the editing would be constrained to that specific department. You could try user or role based access constraints within your DBMS but I'm not sure how SDE will like that.

[JakeSkinner]

As a workaround, you can use the 'sdelayer -o grant' command to accomplish this.  Ex:

GIS.Vector.Topology (feature dataset)
     -GIS.Vector.Boundaries (feature class)
     -GIS.Vector.Tax_Districts (feature class)

If I want to grant another user, ie 'Raster', to be able to just view & edit the 'Boundaries' feature class the command would be:

C:\> sdelayer -o grant -l boundaries,shape -U raster -A SELECT,INSERT,UPDATE,DELETE -i 5151 -D GIS -u vector -p vector

The Raster user will not be able to view or edit the 'Tax_Districts' feature class.

[JasonEklund]

Agree completely.  Our GIS is setup so that all our County Departments manage their own data in our SDE database which is managed by myself (GIS Admin).  I have to adjust our feature datasets to allow for proper permissions among departments instead of structuring to fit with topologies and geometric networks.

[FuadAlShunnag]

Yes , this will be very helpful

[AndrewRudin]

We have over 600 layers used for reference of some kind. So we use datasets for organization like alot of users do.  I think there should be two different types of datasets, one would just be to organize data for easy browsing.  The second would be the traditional dataset as is, that is required for advanced geodatabase features like topology and geometric networks.

[RayChilcote]

Agree.  Working for the military a few years back, we asked for this.  Our pitfall was data organization by data content (SDSFIE).  This breaks the potential (and likely) of shared topology requirements when there are two separate owners of data.  Let alone that being in the same dataset then dictates the same precision.

Overall, this would be a nice advancement.

[IanStack]

I agree.  We have FeatureClass level data that participate in a geometric network therefore are all part of a single Feature Dataset.  Different groups are considered data owners for different FeatureClasses and we would like to be able to control editing privs as appropriate.  The goal is to prevent inadvertent editing of data they aren't responsible for without implementing workflows that need to be managed and maintained.

Has anyone confirmed that command line sdelayer -o grant permissions on a FeatureClass circumvent the Dataset level permission management as suggested below by JSkinn3?  Seems like if that works, why can't those permissions be granted via ArcCatalog?