The scenario below affects ArcGIS Pro 2.9, 3.0.4, and 3.1. This behavior is not present in ArcMap and ArcCatalog.
- User1 creates a parent version and sets it to Private.
- User1 creates a child version off the parent version and sets it to Public/Protected.
- User2 opens the Versions view in ArcGIS Pro. They do not see the parent version (expected behavior). They see the child version, and a red square with the hover text, "A parent version is required", appears next to the public/protected child version. The Parent field is blank since the parent version is private.
- User2 creates a new version, deletes a version, or renames a version. The changes are unable to be submitted because the 'Save' button is greyed out. This is due to the red square error described in #3.
- User1 changes the parent version from Private to Protected. User2 is now able to manage versions and save changes.
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).