Access management in openIMIS

3 dimensions:

permissions (https://openimis.atlassian.net/wiki/spaces/OP/pages/1775173658)
- check if an user can do an action, to be replaced by Django perms (we can fake django perms from the current gql logic)
locations
- many object are bound to a specific location, ORM often ensure that the user have access to that location (to be streamlined with helpers)
business permission
- PolicyHolderUser → bound to PolicyHolder
  - Portal policyholder permission should check if the user have a link to the PH managing the ressource: for a contract, the perm check should check that user is tied to contract.recipient.id (policyholder)
  - filter resource is business perms is detected
- Officer → bound to a village (more restrictive that std location, should be manage by std location)
- ClaimAdministrator → bound to HealthFacility
  - HF claim should check that the
  - HF claim list is filtered based on the CA link to HF

Question:

should organization 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)

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

Access management logic:

Only super admin (is_superuser==True) are able to add all roles, any other user with the authority to create user can only add his own role

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

Check if the user has the specified permissions, with optional business-level access control.

This method first evaluates standard Django permissions based on the user's superuser status
and the provided permission list. If standard permissions are insufficient and business-level
permissions are provided, it checks for specific business object access through the
UserBusinessAccess model.

Args:
    perm_list (list): A list of permission strings to check against the user's rights.
        If empty, the method will return True (no permissions required).
    business_perm_list (dict, optional): A dictionary where keys are business objects
        and values are lists of permissions required for those objects. Used for
        fine-grained access control beyond standard permissions. Defaults to None.
    list_evaluation_or (bool, optional): Determines how permissions in perm_list are evaluated.
        - If True: User must have at least one permission from perm_list (OR logic).
        - If False: User must have all permissions from perm_list (AND logic).
        Defaults to True.

Returns:
    bool: True if the user has the required permissions, False otherwise.

Notes:
    - Superusers always have access (returns True).
    - If perm_list is empty or None, returns True.
    - Business permission checking only occurs if standard permissions fail 
      and business_perm_list is provided.
    - For each business object in business_perm_list, the method checks if the user
      has the associated permissions and if they have active access to that object.
    - If a ContentType for a business object cannot be found, an error is logged
      and that object is skipped.
    - The method uses UserBusinessAccess to verify time-bound access to specific 
      business objects.
    - The recursive call to self.has_perms() in the business permission loop 
      may cause infinite recursion if not carefully managed.
    - Missing 'or' operator in the initial has_perm assignment may cause 
      incorrect evaluation of permissions.
    - The has_access check is performed but does not currently affect the return value.

Change to be done:

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
Question : 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

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”