topic Re: Geodatabase version permissions by user in ArcGIS Enterprise Questions

Geodatabase version permissions by user

PaulKroseman — Tue, 27 Oct 2015 16:59:17 GMT

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.

Re: Geodatabase version permissions by user

ChrisDonohue__GISP — Tue, 27 Oct 2015 17:20:41 GMT

Yes, I believe this can be done. For example, in my current position I have permissions which allow Editing and Reconciling a Version, but not Posting.

Now as to the specifics on how to do this, the SDE experts will have to chime in....

Chris Donohue, GISP

Re: Geodatabase version permissions by user

JoeBorgione — Tue, 27 Oct 2015 17:23:37 GMT

(posted moments after Chris Donohue, GISP posted.... I'm no expert but I have been managing a versioned database since version 8.1)

From the 10.1 help:

Private: Only the owner or the geodatabase administrator may view the version and modify versioned data or the version itself.
Protected: Any user may view the version, but only the owner or the geodatabase administrator may edit datasets in the version or the version itself.
Public: Any user may view the version. Any user who has been granted read/write (update, insert, and delete) permissions on datasets can modify datasets in the version.

I keep my 'edit version' as PUBLIC. However, sde.default is PRIVATE. If you have sde.default as Protected, some user will have it open and complain that they can't edit it. You sure don't want sde.default as Public; that's asking for trouble.

Your request seems backwards; no edit privileges but reconcile and post permissions doesn't make sense to me. I like to think of myself as a benevolent system administrator, but I draw the line when it comes to reconciling and posting changes. That's my job. Period.

Just my $00.02....

Re: Geodatabase version permissions by user

RebeccaStrauch__GISP — Tue, 27 Oct 2015 17:30:53 GMT

I would have to agree somewhat with Joe. I think the action of Reconciling, at least, would require editing. And if nothing is edited, I don't see a reason to Post.

Are you just trying to get a version updated, i.e. changed pushed down to a version? Maybe you can create a script to do this.....in fact, there probably is one out there already somewhere. (sorry, no time to look right now).

Re: Geodatabase version permissions by user

ChrisDonohue__GISP — Tue, 27 Oct 2015 17:37:26 GMT

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

Re: Geodatabase version permissions by user

PaulKroseman — Tue, 27 Oct 2015 18:05:27 GMT

I want to allow a QA/QC user to be able to post to DEFAULT but I don't them able to edit on DEFAULT. End users should be able to post to the QA version when they have finished an edit in their version, but should not have edit on the QA version. Maybe I'm thinking backwards.

There is also another group that has their own data/version tree. They perform their own edits and push to DEFAULT, but don't need geodatabase admin priveleges. Setting DEFAULT to Protected would require me to post all of their edits or give them sysadmin in the database. I only create datasets/feature classes for them.

Re: Geodatabase version permissions by user

JoeBorgione — Tue, 27 Oct 2015 18:16:56 GMT

I want to allow a QA/QC user to be able to post to DEFAULT but I don't them able to edit on DEFAULT.

Seems like a contradiction in terms. Posting does edit sde.default.

They perform their own edits and push to DEFAULT, but don't need geodatabase admin priveleges.Check and see if sde.default is PUBLIC for them; my guess is it is.

Setting DEFAULT to Protected would require me to post all of their edits or give them sysadmin in the database. I only create datasets/feature classes for them.

I guess you'll need to decide what your role in managing the database is. As mentioned, I take control of sde.default. If anything goes haywire on it, the buck stops with me. When you have multiple people 'in charge' you stand to get a blame game of World Series proportions when things go south. Not that it ever happens....

Re: Geodatabase version permissions by user

ChrisDonohue__GISP — Tue, 27 Oct 2015 18:31:10 GMT

So just to confirm, the business need/process is two levels of users (besides the SDE Admin). I'm guessing what you are looking for is something like this:

1. Editor - permission to Edit a Version, but not Reconcile/Post version to default. Once Editors work is completed, notifies QA/QC person to review.

2. QA/QC - permission to View the Editors Version, Reconcile, and Post to default, but not Edit the Version they are reviewing. The QA/QC person evaluates the version, but is not permitted to edit it themselves (instead they notify Editor if changes are needed).

BTW, that sounds like a reasonable setup, if that is the case.

Once you establish the setup you want, you may want to contact ESRI Support for the options to achieve this. They can be reached at: (909) 793-3774. Have your customer number handy, along with the version information for your software/enterprise geodatabase.

Chris Donohue, GISP

Re: Geodatabase version permissions by user

PaulKroseman — Tue, 27 Oct 2015 18:51:43 GMT

I want to allow a QA/QC user to be able to post to DEFAULT but I don't them able to edit on DEFAULT.
Seems like a contradiction in terms. Posting does edit sde.default.

I don't want them to start an edit session or run a tool directly against DEFAULT. Posting is fine.

They perform their own edits and push to DEFAULT, but don't need geodatabase admin priveleges.Check and see if sde.default is PUBLIC for them; my guess is it is.

Yes it is public. We have only a few users with edit permissions, but will be getting more.

Setting DEFAULT to Protected would require me to post all of their edits or give them sysadmin in the database. I only create datasets/feature classes for them.
I guess you'll need to decide what your role in managing the database is. As mentioned, I take control of sde.default. If anything goes haywire on it, the buck stops with me. When you have multiple people 'in charge' you stand to get a blame game of World Series proportions when things go south. Not that it ever happens....

I manage the database, services, users, etc. But I would like to not be involved in the editing process for data I'm not responsible for.

Re: Geodatabase version permissions by user

PaulKroseman — Tue, 27 Oct 2015 19:01:46 GMT

1. Editor - permission to Edit a Version, but not Reconcile/Post version to default. Once Editors work is completed, notifies QA/QC person to review.
2. QA/QC - permission to View the Editors Version, Reconcile, and Post to default, but not Edit the Version they are reviewing. The QA/QC person evaluates the version, but is not permitted to edit it themselves (instead they notify Editor if changes are needed).

Having the editor contact the reviewer could work.

How do you prevent the editor from modifying DEFAULT and allow QA user to post to DEFAULT? QA user can't be a geodatabase admin.

Re: Geodatabase version permissions by user

ChrisDonohue__GISP — Tue, 27 Oct 2015 19:47:10 GMT

How do you prevent the editor from modifying DEFAULT and allow QA user to post to DEFAULT? QA user can't be a geodatabase admin.

Where I work Editors are prevented from modifying DEFAULT because they do no have the ability to Post (one exception - editors can modify default metadata without reconciling or posting - this is a interesting aspect of SDE I found out the hard way). The Version needs to be reviewed first, then the SDE Administrator does the Post. I'm not sure what permissions have been set for our QA/QC person.

I'm not a SDE expert - just an Editor. But this is an interesting question. I poked around online and found this:

User permissions for geodatabases in SQL Server

ArcGIS Desktop

Also, that brings up some information needed. What version of SDE do you have? Is it tied to SQL Server, Oracle, or another database? The process appears to vary depending upon which combination you have.

Chris Donohue, GISP

Re: Geodatabase version permissions by user

PaulKroseman — Tue, 27 Oct 2015 20:13:53 GMT

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.

Re: Geodatabase version permissions by user

TimothyPitts — Tue, 27 Oct 2015 22:46:41 GMT

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.

Re: Geodatabase version permissions by user

TimothyPitts — Tue, 27 Oct 2015 22:57:06 GMT

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.

Re: Geodatabase version permissions by user

PaulKroseman — Wed, 28 Oct 2015 14:04:38 GMT

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.

Re: Geodatabase version permissions by user

PaulKroseman — Wed, 28 Oct 2015 14:06:19 GMT

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.

Re: Geodatabase version permissions by user

KhalidAbdel-Qader — Fri, 30 Oct 2015 11:56:00 GMT

Yes, I believe this can be done.

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.
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.
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)
After that the administrator can move the change to the SDE.

SDE

POSTMASTER (Child of SDE)

Editors’ versions
(Children of Postmaster)