Blog discussion - branch versioning

7174
19
08-20-2019 10:58 AM
MelissaJarman
Esri Contributor

A series of blogs are released that discuss branch versioning in ArcGIS Pro / ArcGIS Enterprise. This discussion is for questions that are directly related to content/concepts included in these blogs. 

Branch versioning blogs: 

Enterprise GISArcGIS Enterprise

19 Replies
InvenergyGIS_User
New Contributor II

What did you learn about how editors lock the version/service?  How does this work with a field app with multiple concurrent users?  Did they share any new resources? 

0 Kudos
Kathleen_Crombez
Occasional Contributor III

Branch versioning makes me want to retire early also!

ESRI kept saying it is so much easier to administer branch versioned data. But as a long time database administrator, I am finding this to be the exact opposite. Not to mention SQL views are now a serious pain to accomplish without creating a function to extract a versioned view of the default user.

Who ever thought it was a good idea to edit through a service instead of directly through the database and create this versioning scheme where the tables grow exponentially instead of compressing back down after a reconcile and post has lost touch with their user base.

Yes, let's make sure every administrator has to rewrite their simplified code and make them learn a new API just to roll up edits. It's ridiculous!

SeanQuarnstrom1
New Contributor

How can you edit / add to a feature service's Fields / Domains on branch versioned published datasets?

0 Kudos
MelissaJarman
Esri Contributor

You will still be able to perform schema modifications when connected directly to the database connection. This will be performed as the data owner, just as you would for any other registration type.

0 Kudos
AndrewQuee
Occasional Contributor III

The move to a flatter versioning system is welcome because it almost all cases we have no requirement to have versions on versions on a version.  There's change required to production data in multi-user editing, and that's it, so just the one child version per change (which only lasts as long as the edit lifetime) is all we need.  In fact unraveling accidental grandchild versions is the only thing we do with the current multiple layer versioning system.

The move to a service-oriented system is also welcome and a great innovation, allowing much greater flexibility, scope and wealth of applications working with enterprise data across the internet, especially important while staff and clients can both be working from home during COVID-19.

One thing that is a concern though is we currently allow users to create, edit, reconcile and post their versions to DEFAULT (we use customisations to prevent direct editing of DEFAULT) but this seems no longer possible unless we make them feature layer owners or portal administrators.

We'd like to retain the efficiency of self-managed editing with a minimum administration overhead with protected DEFAULT version.  But it's inadvisable leave it unprotected or to make all users of the service Owners and unsafe to make them all Portal Adminstrators just to be able to reconcile and post to DEFAULT.  We'd also like to remain as close to COTS as possible to deliver development and support efficiencies.

What would be ideal for our workflow is if in Enterprise permission can be given to allow classes of users the ability to create, reconcile and post their versions to a protected DEFAULT branch version, but not edit the default version directly.

0 Kudos
MelissaJarman
Esri Contributor

Thanks for your feedback. With the release of 10.8.1 there is a new portal privilege that will allow you to create custom roles for users that need to serve as version administrators for services with the Version Management capability. This will allow you to grant permissions to perform these version administration tasks for branch versioned datasets via services without having to be the service owner or having to be an administrator. 

Under Version Management, you can read about the Manage all privilege. 

User types, roles, and privileges—Portal for ArcGIS | Documentation for ArcGIS Enterprise 

Currently, this portal privilege is an all-encompassing privilege that is not separated into individual tasks: 

 Your comment about being able to post to a protected default while not being able to directly edit the protected default version is interesting. This is a request we have heard from others users as well in discussion. Please feel free to elaborate on what workflow this would help facilitate.

0 Kudos
JohnAnderson1
New Contributor III

Hi Melissa Jarman‌ I work with Andrew Quee‌ and I can elaborate on the topic of workflows. Essentially we want to give editors in our organisation access to creating child versions from DEFAULT, editing versions, and then reconciling and posting, but we don't want to allow editors to edit the DEFAULT directly. This is because we don't want editors to accidentally edit DEFAULT, but we do want to give them the flexibility to edit data using long transactions and to Post edits to DEFAULT from their child version. To achieve this in the past we built a custom ArcMap Editor extension which listened to Editor Events such as Start Editing and raised an error if the workspace was the DEFAULT version. The disadvantages with this option is that it requires coding/customisation and the user needs to editing in ArcMap and have the Add-In installed. It would be helpful if Portal and ArcGIS Pro could be configured to achieve this without custom code.

To elaborate a step further, our old ArcMap workflows also required that editors validate any new or modified features (that were created/modified in the child version) before they post to DEFAULT. We have also enforced this with code and using Data Reviewer, but it was tricky because there is no ArcObjects API for Data Reviewer - we had to use a combination of ArcObjects, Python, and Data Reviewer geoprocessing tasks. So yeah, an additional configuration in Portal / ArcGIS Pro that enforced data validation prior to version posting would also be very useful!

We are currently investigating ArcGIS Pro Tasks and Workflow Manager to see if they can provide a better solution (than coding), however sometimes the out-of-the-box options end up requiring more clicks of the mouse and are less efficient.

0 Kudos
MelissaJarman
Esri Contributor

Thanks for the additional information John! This helps to understand your workflows and it is just a simple preference that users not directly edit default. You do trust these same users to post to default, but would also prefer to add additional requirements prior to post such as validation. 

We currently have validation attribute rules that can be evaluated via services, but there is currently not a way to force validation to be run before posting. Until a solution like this is available out of the box....

You could use the ArcGIS Pro SDK to remove the default Post button and replace it with custom code the runs validation first.

AndrewQuee
Occasional Contributor III

Yes, this is exactly what we are doing now in Desktop and Pro business systems.  We were hoping to return to somehting more COTS-like and reduce development overheads is all.  Thanks for the clarification.

0 Kudos
SeanRedar
New Contributor III

When setting up for branch versioning do you generally recommend using headless admin accounts for the both the RDBMS and portal sides?   The documentation seems to indicate that all access control rest in the Portal side.

0 Kudos