I’m writing an integration which manages the lifecycle of supervisor accounts in eCHIS. The accounts in eCHIS are linked to my integration tool by their oidc_username and they login to eCHIS using SSO.
Each user’s facility_ids are also managed by the integration and the goal is for areas to exclusively managed (only user owner at a time).
Here is a scenario I’m struggling with: "Invalid facilities list"
User A is assigned to facilities {1, 2}
User B comes along and is assigned to facility {1}. This is exclusive, User A loses their assignment.
User C comes along and is assigned to facility {2}. This is exclusive, User A loses their assignment.
At the end of the scenario, User A is expected to have no facilities.
Today, I’m seeing the call to api/v3/userswhich updates them to have an empty facility_id return 400 with { message: "Invalid facilities list", key: "field is required", field: "Place" }.
I could disable this user, but this would mean their password gets lost and it is very hard to reassign them again. Their user account should still exist - I want to be able to reassign them areas to manage in the future.
Does it seem reasonable for users to have empty facility_ids and this to be a bug/improvement in CHT Core? I know the Uganda project never disables users, instead electing to assign them role: "disabled" to effectively revoke all permissions. Is that encouraged? What other options exist?
I think that we have always considered an offline user without a facility as an “invalid” state, and all of the old user creation endpoints have always required a facility_id for offline users. The v3 respects this requirement, and I would expect it not to allow updating a user with no facility_ids.
This scenario results in 14 non-transactional calls to CHT which seems kinda absurd to me, but I guess that’s what it takes.
User A manages {A1, A2}. Both A1 and A2 share one primary contact P (a single person doc under A1), and P is User A's contact. Reassign A1 + A2 from User A to a new User B.
Updating the user with facility_ids of graveyard returns 404 even when the graveyard exists. The graveyard needs to be a valid place (county, subcounty, CHU, etc) which would also mean it appears in the UI, would appear in dashboards and analytics, etc. I’m not willing to do that.
I could make graveyard a new valid contact_type, but then every project using UMT would require that configuration? And it would appear in the UI? That also seems quite undesired.
I guess I’m going back to role: disabled with just random whatever values on facility_id.