Access management in openIMIS

The three dimensions of access in openIMIS

openIMIS controls what users can see and do through three complementary dimensions:

Dimension	What it controls	Typical use	How it works in practice

Dimension	What it controls	Typical use	How it works in practice
Permissions	What actions a user is allowed to perform	Submit claims, view policies, approve, etc.	Based on roles and specific permissions
Locations	Which part of the organisation the user can see	District, Region, Health Facility	Usually filters lists and searches automatically
Business Access	Specific business objects the user is responsible for	One or more Health Facilities	Explicit link between a user and concrete objects

How the access logic works

The three dimensions work together, but with a clear priority rule:

SuperAdmin: have all perms
General permissions (the classic role-based rights) give broad access. If a user has the general permission for an action, they can perform it (within the limits of their location assignments).
Business Access only comes into play when the user does not have the general permission. In that case, the system checks whether the user has a specific Business Access record combined with a Business Access permission for that action.

In short: General permission = broad access (subject to locations). Business Access + UBA-specific permission = alternative, more granular access path that is used only when the general permission is not granted.

Real-life example – Submitting claims for a Health Facility

Case 1 – User has the general permission A user who has the general “submit claims” permission can submit claims for the Health Facilities they are allowed to see through their location assignments. No Business Access record is required.

Case 2 – User does not have the general permission A user without the general “submit claims” permission can still submit claims, but only for the Health Facilities where they have:

A Business Access record linking them to the Health Facility (as claim_admin), and
The specific Business Access permission to submit claims (uba_ca_claim_submit).

This way, organisations can give very precise access without granting the broad general permission.

Why this approach improves on the previous model

Previously, Claim Administrators and Officers relied on a role plus a dedicated model that filtered data via get_queryset. This was rigid and hard to adapt when responsibilities changed between Health Facilities.

The new Business Access approach offers more flexibility:

Users with general permissions continue to work as before.
Users without general permissions can still be given targeted access to specific Health Facilities through Business Access + specific permissions.
Reassigning someone to a different Health Facility is simple: just add or remove the Business Access record.
Everything remains fully auditable.

Summary

openIMIS manages access through three dimensions — Permissions, Locations, and Business Access — that work together with a clear rule: general permissions provide broad access, while Business Access provides a precise alternative path when general permissions are not granted.

The most common use case is giving Claim Administrators (and similar roles) access to the specific Health Facilities they are responsible for, without necessarily giving them wide general permissions.

This improved logic is now available in the core of the system (openimis-be-core_py).

Question:

should entity (mutli tenant) be managed by business permission or should we have a dedicated field on the use
should we transform TechnicalUser (unused) to ClientUser (Insuree … ) to ensure the we don’t mix client and real user and we could have different Auth methods (could be achieved with is_staff but I fear missconfig give too much acces to client)
Should we create a “contact” table to have CA without user ? (could be reused for practitioner) or have a user that cannot login
- reuse individual + some kind of many to many

User business Access create a more generic UserBusinessAccess class that could link the user to any object (PR146) migrate PolicyHolderUser and CA to UserBusinessAccess update the FE user location picker to be more flexible rework location check logic (tied to user_disctrics) migrate Officer to normal InteractiveUser but with limitation on village level create business right for CA SuperUser add a is_superuser attribute to interactive user (PR146) migrate user with is_imis_admin (fct)== True to is_superuser (attribute) = True (PR146) has perm need to check is_superuser (drop is_imis_admin logic) (PR146) support UserBusinessAccess in has_perms (PR146) add on the FE a is_superuser checkbox, editable only for admins only admin should have db_creator role (or we remove that capacity to all users because too dangerous) only admin should be able to do backup or restore (or we remove that capacity to all users because too dangerous) stronger encryption of passwords Django createuser and createsuperuser should create Interactive user (PR146) CA table should become a view for compatibility (resp for officer) id = User ID uuid = user UUID code = user login lastname = User Name other_name = User other name dob = user DOB (to be added if not existing) email_id = user email phone = user phone HF = HF user HF Migrate to user business access add HF user specific authorities PortalRead that will require a link to the HF in addition to the right have an helper to check the right per level of location and adapt all queries to use it (could be a function that return a filter) Done: LocationManager.build_user_location_filter drop the EO table (use normal user + location = village or disctrict create a EO view for compatibility

Change to be done:

Action upon deletion of an user

all related access must be “deleted“ too (flag deleted to True)

Action upon deletion of an user with business acess

in all case the relation between the users and the external partner must de “deleted“ too

Quesiton: if the users are only related to that given external partner (have no relation to other external partner) then the user must be “deactivated”

Access management