In the world of branch versioning, more than just editing takes place via services. A majority of the version management operations and workflows also occur when accessing the geodatabase workspace via a web feature layer. This means that portal users will perform tasks like creating a version, reconcile, and post all via services.
I want to take the time to explain the components that control what portal users can access, edit, and manage versions for branch versioned datasets as this impacts branch versioning administration workflows. Having a better understanding of this will help you configure your services and portal users to best serve your organization.
How does the magic happen?
There are several moving pieces that come together when working with branch versioned data via services. The Version Management capability controls what operations are available on the service itself in regards to versioning workflows. The ability to create and edit named versions is possible thanks to this capability enabled when publishing branch versioned data as a feature service. Version management also enables many tasks in version administration workflows such as the ability to reconcile, post, modify version properties, and delete versions for the service.
From here, the specific ArcGIS account signed into the active portal will determine what operations are allowed for branch versions. Version access is based on a combination of the active portal user’s privileges and the access permission of the version (public, protected, or private). Keep the following in mind:
- All users can view, edit, and manage branch versions they own
- All users can view public and protected versions
- Protected and private versions can only be edited by the version owner and the version administrator
*Note that branch versions are only available in the service in which they are created.
The term version administrator is used to refer to portal users that have higher privileges to perform version management tasks for all versions in a service. Depending on your organization, this could be the same portal user that publishes the service, a portal administrator, or a group of users that share the version management responsibilities.
The following are examples of version management tasks that a version administrator can perform:
- View and edit versions owned by other users (public, protected, or private)
- Perform reconcile operations for versions owned by other users (public, protected, or private)
- Perform post operations for versions owned by other users (public, protected, or private)
- Modify version properties for all versions
- Delete branch versions owned by other users
- Manage version locks for all versions
What portal users are version administrators?
There are several ways in which a portal user can serve as the version administrator for services that include branch versioned datasets. Let’s review these, so you can find a method that works best for your organization.
For ArcGIS Enterprise, the following portal accounts can serve as the version administrator:
- The service owner – the user that publishes the service
- Portal accounts with administrative privileges – portal administrator or users with the default Administrator role
- Portal accounts assigned a custom role with the Version Management – Manage All portal privilege (10.8.1 and later)
Manage all portal privilege
For portals that are using ArcGIS Enterprise 10.8.1 and later, a Manage all portal privilege is available to allow users to perform version management tasks. This is helpful if you have a portal user that needs to perform version management tasks, but does not need to have administrative level privileges in the portal.
You might be wondering how exactly do I use this privilege? The Manage All privilege is not included in most of the default roles (with the exception of Administrator), so to use it you will need to create a custom role. When creating a role for your organization, you can set the role privileges from an existing role as a baseline. This allows the role to inherit all the privileges from an existing default role and from here you can enable the Manage all privilege. The Manage All privilege is located under General privileges > Version Management. Note that you will need to ensure that the Privilege compatibility slider is set to View, edit, create and manage to enable the Version Management – Manage all privilege.
After the role is created, you’ll set this as the role for portal users that are going to serve as version administrators. This can be done under Organization and the Members tab by using the Role dropdown for the ArcGIS account to select the Version Administrator custom role.
Voila! Members with this custom role will have the ability to serve as the version administrator for services that they have access to in the portal.
What about the geodatabase administrator?
With all this talk about the version administrator for branch versioning workflows, are there any version management tasks left for the geodatabase administrator?
The geodatabase administrator is a database user that performs version management tasks for traditional versioning. While most branch versioning administration tasks are performed via services, there are a few items reserved for the geodatabase administrator.
The geodatabase administrator can perform the following tasks when accessing the geodatabase directly from a database connection:
- Delete versions still referencing services that no longer exist in the portal – this is handy if you have deleted a service that still has outstanding versions
- Manage access privilege of the default version – this is important to review when determining how you will safeguard the root version of the geodatabase for service users.
- View all branch versions in the geodatabase using the Versions view – this includes all services
I hope you now have a better understanding of the version administrator and what portal users can perform version management operations when working with branch versioned data. Use this information to decide how you want to setup your services and portal users so that these tasks can be completed by users you trust, just as you would your geodatabase administrator.