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.
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
(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:
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....
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).
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!)
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.
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....
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.
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.
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.
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.
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.
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.
Timothy Pitts wrote:
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.
Yes, I believe this can be done.
SDE
POSTMASTER (Child of SDE)
Editors’ versions(Children of Postmaster)
サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
