Execute planned migration

[mehansen]

Background

We would like to migrate user roles, org membership, and facility membership to be stored within the SimpleReport app, as opposed to managing it in Okta. This will increase stability of the app and improve code readability and extensibility, among other benefits. The goal of this ticket is to migrate user data from Okta for any users whose data was not updated during the rolling migration.

Change requested

For any API Users that do not have data in the ApiUserRole table, use our existing mutations to copy the role and facility/org information stored in Okta to our tables.

• all users should have 1-2 roles in the UserRole table, but not all users will have facility assignments in the UserFacility table For users that do not have any facilities assigned in Okta and also don't have the ALL_FACILITIES role, they should still have their auth data migrated over. Beware the exception we throw when trying to save users with no facility access that might prevent the data from being saved.

Acceptance criteria

• all users have their updated role and facility stored in our tables
• role and facility data in our tables is in sync with what's in Okta for all users, even users with invalid facility access

Dependencies

• #7598

Open questions

Questions to address in refinement:

• (maybe need additional spike?) After what period of time should we do the planned migration? 60 days after rolling migration code has been merged?
• If we're doing batch migrations, how can we "remember" the batches so we don't miss anyone?
• Can we just write a script that for every user in user table: execute a user role/facility info query? that would trigger the comparison/update code implemented in the rolling migration for all users
• What's expected behavior for: users with no Okta account, deleted users, Okta accounts with no match in Api User table?
• What happens if a user is edited by an admin while the planned migration is going on

Notes

If a user is inactive in Okta for 60 days, that user Okta status is set to suspended (deactivated on frontend). The user can't log in unless a support admin or their org admin activates them from the Manage users tool.

Before the migration, ask support to make any user reactivation an escalation ticket until we have completed the process.

Additional context

Main design doc Design doc - backend Design doc - data migration plan Okta migration tickets plan Okta tech talk Okta tech talk part 2