Allow users to manage versions when there is a private parent version owned by another user

[GeoffreyDeLano]

The scenario below affects ArcGIS Pro 2.9, 3.0.4, and 3.1. This behavior is not present in ArcMap and ArcCatalog.

1. User1 creates a parent version and sets it to Private.
2. User1 creates a child version off the parent version and sets it to Public/Protected.
3. 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.
4. 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.
5. 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).

[BillFox]

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.

[GeoffreyDeLano]

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.