Geodatabase version permissions by user

[PaulKroseman]

Is it possible to grant/restrict which actions users can take against a version?

I would like a user to be able to reconcile and post to a version, but not directly edit on that version.

[PaulKroseman]

I would guess all of your versions are set as Protected. I don't see a way to prevent posting to or editing a Public version.

[TimothyPitts]

The way we have it set up, DEFAULT is protected, QAQC and individual child versions are public. Editors work in their versions and R&P up to QAQC. It's mostly SOPs and business practices that keep the editors in order.

I have the ability to edit DEFAULT, so I can R&P from QAQC to DEFAULT if needed, but I don't do much editing and when I do, I use my own child version. Usually, the R&P to DEFAULT is done by script overnight, so all quality checks need to be done before close of business. The script also replicates from DEFAULT into our Production SDE.

Every weekend, we have a script that R&Ps all versions up into their parents and deletes them, runs a compress, and then recreates all the versions.

[PaulKroseman]

Writing a procedure for editors to follow, rather than rigid permissions, sounds like the best option.

I could create a public version that QA posts to then use a script to post that to DEFAULT.

[ChrisDonohue__GISP]

I believe besides what Joe Borgione posted (on Private, Protected, Managed) there is another level of permissions in SDE assigned by the SDE Administrator.  For example, there are many datasets in our City SDE that I can only view, whereas the Landbase that my group is responsible for I have expanded access to so I can Edit and Reconcile. Our SDE Administrator apparently sets permissions by a group policy; recently our team suddenly all got "upgraded" when we inherited a new set of datasets from another department.

Also, as Joe stated, it is unusual to specify that someone be able to Reconcile and Post but not Edit.  Not that you want someone doing all three aspects, but it seems the permissions "cascade down".  For example, the SDE Administrator is "god" - she/he can do anything permission-wise.  That's my 2 cents (added to Joe's contribution you are up to 4 cents!) 

Chris Donohue, GISP

[TimothyPitts]

We use Active Directory to manage users, so it is definitely not preferred to try to manage user permissions at the database level since we'd need custom roles to do that. Currently, we have three roles: GIS Admin, GIS Editor, and GIS Viewer, with obvious database privileges attached at each level.

We are discussing adding department-level GIS roles (Utilities Editor, PW Editor, etc.) and giving edit permissions to only the datasets appropriate to that group. We haven't done that so far, because 1) we're a small enough group that I think we can use business rules to handle this (e.g., use Production data for everything except the one feature class you are editing); and 2) we don't give editing permissions to non-GIS staff, others can use file geodatabases that we can pull the relevant data out of, if needed.

[PaulKroseman]

Timothy Pitts wrote:

We use Active Directory to manage users, so it is definitely not preferred to try to manage user permissions at the database level since we'd need custom roles to do that. Currently, we have three roles: GIS Admin, GIS Editor, and GIS Viewer, with obvious database privileges attached at each level.

That was my plan. Use AD groups for Admin, Editor, Viewer for users. Dataset permissions assigned to roles. Currently all edit roles are assigned to Editor group but I could create a group for each role if I want to restrict more.

[KhalidAbdel-Qader]

Yes, I believe this can be done.

1. You can make the SDE Protected
   Any user may view the version, and they can‘t do any change to it, the owner or the
   geodatabase administrator may edit datasets.
2. Make a copy of the SDE call it POSTMASTER and it also protected no one
   can edit the postmaster but they can create a version of it.
3. Editors create versions as a child of the POSTMASTER and they can post
   and reconcile to the POSTMASTER and that will catch any conflict between the
   editors. (if any)
4. After that the administrator can move the change to the SDE.
   

                                                                                     SDE

POSTMASTER (Child of SDE)

Editors’ versions
(Children of Postmaster)