Visibility should be set to 'Private' when modifying a pre-existing list that meets cross-tenant criteria
Description
This story will be for testing only – required changes will be enforced in
Some lists that meet the criteria for having a cross-tenant query have a visibility set to ‘Shared’ (these lists were created prior to enforcing ‘Private’ for visibility in the UI, or were created via API).
When these lists are edited via the Lists UI, the visibility should be set to ‘Private’ (same as we enforce for new lists). The current behavior is the list is set to ‘Shared’ and cannot bet changed to ‘Private’.
Additionally, the API should enforce that these lists can only be created as ‘Private’.
Pre-condition:
Pre-existing list that meets the criteria for a cross-tenant query** AND the visibility is set to shared
**List in the central tenant for Instances, Holdings, Items records
Steps to reproduce:
Open the existing list
Click ‘Actions – Edit list’
Expected results:
List visibility is set to ‘Private’ and cannot be changed
Actual results:
List visibility is set to ‘Shared’ and cannot be changed
Scenario 1: Editing a list that contains a cross tenant query that was previously set to ‘Shared’
Given a list matches the criteria for a cross-tenant query
And the current state of the list visibility is ‘Shared’
When the list is edited
Then the list visibility is set to ‘Private’
And the "Shared" radio button label and circle become disabled
And a lock icon appears next to ‘Private’
And the ‘Private’ visibility is saved when the list is saved
Scenario 2: User cancels edits on a pre-existing list that meets cross-tenant criteria
Given a list matches the criteria for a cross-tenant query
And the current state of the list visibility is ‘Shared’
And the list is being edited
And the list visibility is set to ‘Private’ (scenario 1 above)
When the user closes the list without saving changes
Then the updated visibility is not saved
note: if we need to notify the user that the visibility is being set to private, we can probably use the same type of messaging we do when someone chooses ‘inactive’
This story will be for testing only – required changes will be enforced in
Some lists that meet the criteria for having a cross-tenant query have a visibility set to ‘Shared’ (these lists were created prior to enforcing ‘Private’ for visibility in the UI, or were created via API).
When these lists are edited via the Lists UI, the visibility should be set to ‘Private’ (same as we enforce for new lists). The current behavior is the list is set to ‘Shared’ and cannot bet changed to ‘Private’.
Additionally, the API should enforce that these lists can only be created as ‘Private’.
Pre-condition:
Pre-existing list that meets the criteria for a cross-tenant query** AND the visibility is set to shared
**List in the central tenant for Instances, Holdings, Items records
Steps to reproduce:
Open the existing list
Click ‘Actions – Edit list’
Expected results:
List visibility is set to ‘Private’ and cannot be changed
Actual results:
List visibility is set to ‘Shared’ and cannot be changed
Scenario 1: Editing a list that contains a cross tenant query that was previously set to ‘Shared’
Given a list matches the criteria for a cross-tenant query
And the current state of the list visibility is ‘Shared’
When the list is edited
Then the list visibility is set to ‘Private’
And the "Shared" radio button label and circle become disabled
And a lock icon appears next to ‘Private’
And the ‘Private’ visibility is saved when the list is saved
Scenario 2: User cancels edits on a pre-existing list that meets cross-tenant criteria
Given a list matches the criteria for a cross-tenant query
And the current state of the list visibility is ‘Shared’
And the list is being edited
And the list visibility is set to ‘Private’ (scenario 1 above)
When the user closes the list without saving changes
Then the updated visibility is not saved
note: if we need to notify the user that the visibility is being set to private, we can probably use the same type of messaging we do when someone chooses ‘inactive’