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.

[ChrisDonohue__GISP]

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

[JoeBorgione]

(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....

[RebeccaStrauch__GISP]

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).

[PaulKroseman]

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.

[JoeBorgione]

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....

[PaulKroseman]

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.

[ChrisDonohue__GISP]

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

[PaulKroseman]

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.

[ChrisDonohue__GISP]

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