Testing Supervisor Related Features

[Benmuiruri]

This issue tracks the results of manual testing the features of the supervisor related features that allow users to be associated to two places.

The testing involves making sure no bugs were introduced by the changes.

The testing comprises of reviewing:

• Backend changes
• Webapp Frontend changes related to Contact list. The expected changes are described in this PPT
• Webapp Frontend changes related to targets and targets aggregates . The expected changes are described in this PPT
• Webapp Frontend changes related to breadcrumbs. The expected changes are described in this PPT
• Admin app Frontend changes

Testing all Supervisor Stuff

1. If the user has more than one facility_id:

• Only show the facilities they are assigned (homeplaces), DO NOT show the children of those facilities on the LHS Contact list
• Display the "places" card in the Contact detail view to display the child places on the LHS Contact list.
• DO NOT show the sort option.
• DO NOT set the light-grey background for the homeplaces
• When can_aggregate_targets is enabled user CANNOT see the aggregate targets page.
• In Reports Page | List view show breadcrumbs for the place associated with a contact
• In Messages Page | List view show breadcrumbs for the place associated with a contact
• In Tasks Page | List view show breadcrumbs for the place associated with a contact

2. If the user has just one facility_id

• Show facilities they are assigned (homeplace) and the children of the homeplace
• DO NOT show the "places" card in the Contact detail view
• Show the sort option
• Set the light-grey background for the homeplace
• When can_aggregate_targets is enabled user can see the aggregate targets page.
• In Reports Page | List view DO NOT show breadcrumbs for the place associated with a contact
• In Messages Page | List view DO NOT show breadcrumbs for the place associated with a contact
• In Tasks Page | List view show DO NOT breadcrumbs for the place associated with a contact

3. In the Admin app

• Check that all previous validations for name, role, place, contact and password are working as they were.
• Create user with one place.
• Try editing a user with one place, the place should be prefilled in the form.
• Try editing a user with one place to set two places if they don't have a role the can_have_multiple_places permission.
• Try editing a user with one place to set two places if they have a role with the can_have_multiple_places permission.
• Create user with two places.
• Try editing a user with two place, the two places should be prefilled in the form.
• Create user with three places
• Try creating user with multiple places without enabling can_have_multiple_places permission.
• Try creating user with two places that are not in same hierarchy level
• Try creating user with one place where the contact is not a child of selected place
• Try creating user with two place where the contact is not a child of both places.
• Try creating user with two place where the contact is a child of one of the places.

PS - While testing try to think of edge cases as much as possible

[michaelkohn]

@Benmuiruri I'm not sure the best way to manage a growing list of test scenarios, perhaps just edit / add to the first comment and then react with a 👍🏼 on this comment once they have been acknowledged or added/updated, but here are some other funky scenarios to consider.

1. Update a user that previously had one facility to now have multiple facilities
2. Update a user that previously had multiple facilities to now have one facility
3. Remove the permission from a user that already had multiple facilities assigned
4. Set up a user that can create places at the same level as their assigned place(s). (note, we are not expecting to support this, but i want to make sure it doesn't bring down the system or something else weird)
5. There should be some tests to make sure the "My Targets" still works

[michaelkohn]

Issue with Reports Page Filter. I'm not sure it has to do with the work we are doing now, but I just noticed it here and can't replicate it in other environments. I tried to test this on https://demo-cht.dev.medicmobile.org/#/reports but I think it has a different setting for place_hierarchy_types (in app_settings) so it doesn't show HHs in the Place filter. I also tried it on https://care-teams-4x.dev.medicmobile.org/#/reports, and it seemed to work fine but there's a lot of data and hard to know for sure.

There are two issues illustrated in the video...

1. Not showing data when it should
2. Showing data it shouldn't

Reports.Tab.-.Filter.Not.Working.Correctly.mp4

[Benmuiruri]

Testing Findings

1. Reports filter has unexpected behavior when you filter to a certain depth. However, this behavior is also on Master branch so it is not related to our work
2. Reports filter related to our multi-facility branch also has unexpected behavior. When you filter to see only reports associated to CHU-A, you see reports associated to CHU-B. Then when you filter reports associated to CHU-B you see no reports.

• Here is a video of that behavior

Screen.Recording.2024-06-04.at.12.26.57.mov

3. When you move contacts from one user to another you end up with a situation where the user still sees the data that they should not. For example, a user who previously had two facilities (CHU-A and CHU-B) and get's reassigned to one facility (CHU-A) will continue to see the places belonging to CHU-B. Perhaps something to keep in. mind when writing the documentation

• Here is a video of that behavior

Screen.Recording.2024-06-04.at.12.38.35.mov

Overall, those are the three issues I found. All other behavior is as expected in the Issue description above.

[michaelkohn]

@Benmuiruri can we get rid of the second error message? I think that error should only be shown if the Place is blank/nothing selected.

All users must be associated with a place in the system to be correctly located in the hierarchy and see appropriate data when they log in.

[michaelkohn]

@Benmuiruri The issue is that none of the selected roles have the required permission. I think we should change the error message...

Instead of: The person with selected role cannot have multiple places
Something like: None of the selected roles allow assignment of multiple places

@n-orlowski Any recommendations for improving this wording? 👆🏼

[n-orlowski]

The selected roles do not have permission to be assigned multiple places

[ralfudx]

I've completed testing on this from my own end and didn't find anything new
@Benmuiruri @michaelkohn qq: are we looking at having the message change as part of this PR?

[Benmuiruri]

Yes @ralfudx we are. I have made the change in the PR