[Move user] Org access tab on Manage User page

[mehansen]

Why are we doing this?

Problem: SimpleReport users sometimes encounter difficulties when attempting to add a user to an organization. This is causing an increase in support inquiries and delays in issue resolution for end-users.

Moving users or undelete/add user requests make up about 50% of all support requests and is an error-prone, time-exhaustive process for our engineers to implement in Okta. From the users’ perspective, they are trying to invite someone that already exists in SimpleReport to another organization. This leads to an error message that this can’t be done. No guidance is provided to users on how to address this issue or how to move users between orgs. As a result, the user escalates this to support.

• Users that are trying to transfer to a different org are mistakenly using the “Sign Up” flow to create a new organization.
• New non-patient users are unable to determine if the organization they belong to already exists in SimpleReport before signing up for a new account.
• One email address cannot have multiple accounts and can’t be in more than one organization at the time. This constraint exists everywhere in the code.
• It is not possible to hard delete users. You can only soft delete users. So when you try to re-add a user, you get the error that “this user already exists”.

Action Requested

Create a new "Organization access" tab on the "Manage Users" screen that displays information related to the user's associated organization, facilities, and role. From this view, Support Team members should be able to change a SimpleReport user's organization, grant access to facilities, and change the user's role and permissions.

Acceptance Criteria

• The "Organization access" tab is added to the Manage Users screen.
• The tab displays information related to the user's organization, facilities, and role.
• Support Team members can change a user's associated organization, grant access to facilities, and change the user's role from the "Organization access" view.
• The UI checks for test results reported under the current organization before allowing an update of the organization.
• The UI disables the organization dropdown until the test result check is completed.
• If there are test results reported, a warning is displayed to the support admin, calling out the loss of data and suggesting confirmation with the user before moving to the new org.
• A modal with a warning is displayed after clicking on "Save Changes" if the test result count endpoint detects results under the organization and the support admin makes an org change in the dropdown.
• The mutation "updateUsersPrivileges" is called upon clicking "Save Changes" to update the user's access.
• The application ensures that before adding a user to the necessary Okta groups for the new organization, the user is removed from the previous groups.
• The "updateUsersPrivileges" endpoint is modified to support updates of organizations or a new endpoint is created.
• The updateUsersPrivileges endpoint is checked to make sure that Super Users are the only ones allowed to request for organization changes.
• if role chosen is Admin, user doesn't need to select facilities (should behave like it does in Facility access tab on org admin Manage users view)

Additional Context

Organization access tab
The purpose of this tab is to allow support admins to update the roles and organization of an user. Before allowing an update of organization the application needs to check that there are no test results reported under the current organization where the user is currently assigned. The reason is that the moment the user moves to the new organization it will lose access to any data reported under the previous one. To perform this check the UI will need to call the query testResultCount upon loading. It is recommended that UI disables the organization dropdown to avoid changes until the testResult check is completed.

If it is determined that there are testResults reported then the UI should display a warning to the support admin calling out the loss of data and a suggestion to confirm with the user that the move to the new org is indeed the path forward. Another more restrictive solution is to block the change of organization completely but this could end up in support admins needing development assistance still.

Constraints
There is no operation that allows checking if there are test results reported under an organization. The operation testResultCount is currently used to check if there are test results reported under a facility or for a patient but does not support filtering by organization.

Suggestions
Update the query testResultCount to accept an organization Id in its parameters and return the number of results under that organization.

Show a modal with a warning after clicking on save changes only if the testResultCount endpoint detected results under the organization and the support admin made an org change in the dropdown.

Saving changes
After the support admin has updated the role and/or organization the save changes button will become enabled. Upon clicking of the button the mutation updateUsersPrivileges will be called to update the user’s access.

Constraints
The mutation updateUsersPrivileges, currently used in the Manage users page within settings, does not support updates of organizations. It only allows updates for roles and facilities so there is no operation available to move a user to an org.

The application also needs to make sure that before adding a user to the necessary okta groups for the new organization the user is removed from the previous groups.

Suggestions
We have two options:

1. Create a new endpoint to support the access changes. If we follow this path we would need to make sure that we can reuse the current logic to allow for role updates.
   Reuse the updateUsersPrivileges endpoint to accept the updates on organizations. This option gives us the ability to update roles for free but will need us to add checks to make sure that Super Users are the only ones allowed to request for organization changes.

2. Alternate: Currently the createUserInCurrentOrg call does allow deleted users to be re added to the same organization. During this reprovision step we throw an error if the user’s claims do not match the same organization. We could refactor this to allow this logic by simply removing the existing claims. (This could be implemented for the organization admin -> undelete user flow so by default putting back the user to their previous org as soon as they become undeleted but the organization admin cannot see deleted users so they won’t be able to trigger the undelete action)

References

• Figma
• Manage users (Support admin) [Google Doc]
• SPIKE: Self-Service for Support Team - Move user to a different organization SPIKE: Self-Service for Support Team - Move user to a different organization #5707 [ZenHub]
• SimpleReport Product Spec:Moving users between organizations [Google Doc]

[mehansen]

Blocked by #6161 and #6162