The scenario below affects ArcGIS Pro 2.9, 3.0.4, and 3.1. This behavior is not present in ArcMap and ArcCatalog.
Parent version owner sees (User1, WPDR_ADMIN in image):
Other users see (User2, GDELANO in image):
Other user (User2, GDELANO) tries to create a new version:
Setting parent versions to Protected is definitely best-practice. However, the scenario above creates unnecessary pain points when administering a geodatabase with multiple parent/child version trees and many users of various experience levels. ArcMap and ArcCatalog do not exhibit this behavior. I submitted a support ticket (case #03358043), and an ESRI rep confirmed that this is expected behavior in Pro and not a bug.
If this behavior remains, then ArcGIS Pro should block users from setting child versions to Public/Protected if the parent version is Private (child version must also be Private), and ArcGIS Pro should block users from setting a parent version to Private if there is a Public/Protected child version (parent version must remain Public/Protected).
if I'm reading this correctly, user2 is trying to point to the same parent version as user1
pointing multiple users to the same parent will get you into various (criss-cross) problems
to keep it smooth, set default to protected,
each editor should have their own "Posting" version created for them by an admin user and set to public
then the editors create their own private editing version off of their "Posting" version which they can use to reconcile and post to from their private editing version
then an admin's scheduled task can reconcile and post all the "Posting" versions to default every 15 minutes or so depending on your needs.
User2 is pointing to a different parent version (DEFAULT in the images), and does not need to interact with the private parent version created by User1.
Our department uses a mix of A, B, and C in the image below (taken from the Versioning 101 article). In the scenario I described, User1 would be using C: 3-Level version tree and User2 would be using B: 2-Level Version Tree.
In our environment, the users that own parent versions are responsible for reconciling/posting the child versions and we have a nightly script that reconciles/posts the parent versions up to DEFAULT. Versions that are made directly off of DEFAULT get manually reconciled/posted. This process is not affected by the issue described above.
The main issue is that users are blocked from making any changes to versions if there is a public child version and a private parent version that they can't see (owned by another user). In addition to making new versions, User2 is blocked from deleting any versions they own or even just renaming versions. No changes can be committed until the "red square" is resolved.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.