Add try/catch blocks to methods for retrieving user info

[mehansen]

BACKEND PULL REQUEST

Related Issue

Related to a couple support requests where support admin folks aren't able to load a user using the Manager users page if they don't have access to any facilities.
With our Okta migration code, we are persisting auth data every time we load a user. If the user has an invalid state because of no facility access, we throw an exception and that user's page can't be loaded.

Changes Proposed

Catch the exception potentially created when migrating a user's roles and facilities to the DB only in methods where we are retrieving user info (not updating).

Additional Information

Folks will still get an error if trying to update the target user in any way if the target user is in an invalid state. This seems like a good idea because it'll force users to fix the facility access for that target user if they want to do any updates to them.

Testing

deployed to dev3
you can update a user in Okta to not have access to any groups and check that you can still view them in the org admin or support admin manage users pages

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[fzhao99]

I know that we're assuming in the test case that a user has a NO_ACCESS membership, but wondering if we should try accounting for that? In the event that someone's group membership gets purged, would imagine their NO_ACCESS permissions would probably also disappear, so depending on how complicated it is might want to handle that scenario

Otherwise LGTM!

Screen recording for reference
https://github.com/user-attachments/assets/99aa2824-2a79-4dde-889b-fd5987fa6b0f

[emyl3]

LGTM! Thank you for fixing this, Merethe 😄 🥹

Re: Bob's comment about searching a user with no NO_ACCESS Okta group --Maybe logging the user ID in a separate PR when we throw the OktaAccountUserException can be helpful so we know how frequent this state is and making it easier to debug.

For the purpose of the migration and bug fix, we wouldn't be migrating anything so leaving this as-is seems fine to me.

[mehansen]

I know that we're assuming in the test case that a user has a NO_ACCESS membership, but wondering if we should try accounting for that? In the event that someone's group membership gets purged, would imagine their NO_ACCESS permissions would probably also disappear, so depending on how complicated it is might want to handle that scenario

Otherwise LGTM!

Screen recording for reference https://github.com/user-attachments/assets/99aa2824-2a79-4dde-889b-fd5987fa6b0f

@fzhao99 I believe the behavior of user has no groups -> we show the misconfigured user toast was part of the design of the support admin Manage users page, but maybe that was a miss because it seems like it would be more useful to support admin if they could view a user even if they have no groups.
It might be worthwhile to ask support if they would like this capability but as I think about it more I feel like if a user's groups are getting purged maybe it's best support has to reach out to us because we should probably try to figure out how that would happen.