RA/RM of organization B can include an GeoObject type from organization A in its hierarchy while the list associated to this GeoObject type is private

[SteeveEbener]

List the CGR version information

• CGR version: 0.13.1

Describe the bug (clear and concise) RA/RM of organization B can include a Geo-Object type from organization A in one of its hierarchy while the list associated to this Geo-Object type is private. (Example: the master list of referral hospitals is private. MOHA RA/RM don't see the list but they can see the Referral hospital geo-object type in the geo-object type and hierarchies module)

For organization B to include this Geo-Object type in its hierarchy would mean that it has access to the list but this is technically not possible as it is private.

To Reproduce As the RA/RM from organization A

1. Set the master list for a Geo-Object type as private
2. Submit and log out

As the RA/RM for organization B

1. Go to Geo-Object types and Hierarchies
2. See error: The Geo-Object type form organization A, which list is private, is appearing in the list of geo-object types under

Expected behavior (clear and concise) The public vs private status is also placed on the Geo-Object type in addition to the list and geospatial data, in order to avoid for organization B to select an Geo-Object type for which he does not have access to the data associated to it because it is private.

Once an organization has set a Geo-Object type as private than all the lists and geospatial data associated to it are private as well.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Google Chrome
• Version: 81.0.4044.138 (Official Build) (64-bit)

Additional context (if any)

• Linked to issue #214
• Schema showing the propagation of the public, restricted, private visibility across the CGR platform: https://www.dropbox.com/s/7jrv6zxbvqwkjt0/Public_restricted_private_051020.pptx?dl=0

[justinlewis]

The ticket title and description suggest that privileges of geoobjecttypes and lists are related but they aren't in the way they are described here. However, I think this is understood given the proposed solution highlights a potential solution. I think this ticket needs further discussion to determine how private / public should work between geoobjecttypes and lists.

[justinlewis]

@steeveebener I believe this can be closed because Geo-Object Types now have a public/private option.

[SteeveEbener]

@justinlewis . Can you please describe how the public/private option is supposed to work between the geo-object type and the list before being able to test this.

Note: What I can already mention is that the public/private not being selected from a dropdown but as a checked button is already creating confusion when looking at the metadata for a geo-object types part of a group (option being grayed => give the impression it is always private)

[justinlewis]

@steeveebener

List behavior

If a public list already exists the Geo-Object Type it was created from can not be set to private. Here's the error I got on Staging: The Geo-Object Type [MOH Country (Laos)] cannot be set to private because it is referenced in public master lists.

If a Geo-Object type is private a list can not be created by anyone from other organizations.

If a public list is created from a private Geo-Object Type by the organization who manages it the published lists are available as view only to other organizations. The exploratory section is hidden from people in other organizations.

Hierarchy behavior

If a public Geo-Object Type has a child in one or more hierarchies that are public it can't be made private. Here's an error from Staging: The Geo-Object Type [MOH Country (Laos)] cannot be set to private because it is referenced in public master lists.

If a Geo-Object Type is private people from other organizations can not see that Geo-Object Type in the hierarchy builder.

[SteeveEbener]

Thanks Justin. That explains few things and I am wondering now how these rules were reached because the last time we discuss this, what was supposed to be implemented is what is reported in this schema as per the design meeting dated October 7, 2020 (and as reported in the original ticket): https://www.dropbox.com/s/7jrv6zxbvqwkjt0/Public_restricted_private_051020.pptx?dl=0

The starting point for all of this should be the geo-object type. It does not make sense for a list to be public while the geo-object type is private.

[SteeveEbener]

Tested under 0.18.1 and the problem is still there.

In addition to that, you can't change the visibility of a geo-object type from public to private in case some of the lists that have been created are public. When you try doing this you get the following error message (example for CHW (MOH) geo-object type): "The Geo-Object Type [Community health worker (MOH)] cannot be set to private because it is referenced in public master lists."

[nmceachen]

Needs discussion. The privacy of a GeoObjectType is independent of any lists that have been published from it. As long as the GeoObjectType is not private then this should be allowed.

[SteeveEbener]

The privacy of a GeoObject defines the privacy of any type of information generated on its basis, including the lists as per the schema mentioned in the comment dated Oct 8, 2021: s://www.dropbox.com/s/7jrv6zxbvqwkjt0/Public_restricted_private_051020.pptx?dl=0