Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Access management in openIMIS

Role manangement:

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

Expand
titleChanges to be done :
  • add a is_admin attribute to interactive user

  • change is_imis_admin in the code by is_admin

  • add on the FE a is admin 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)

Access management dimensions:

  • Authorities (CIConfiguration Items, roles and Authorities)

  • Location (CIConfiguration Items, User District, User Village)

  • External affiliation ( Organisation affiliation ? )

    • HF user (CIConfiguration Items, CAClaim Administrator)

    • PolicyHolder User (CIConfiguration Items, PolicyHolder user)

    • Q: should we develop the organization concept, each organisation

      • ORG

        • 0-N services (HistoryBusiness Model), eg. Group policy, Medical Claim, catchment, etc …

          • service as Module that define additionnal tabs in case the service is active (checkbox for unactive service) in addition to the general menu

          • the principle of service iso org type is more flexible

        • 0*-N Users

How access is checked

for Scheme general user:

  • the user role must have the authorities required to the the action and the recipient of the action must belong to a location or service provider within the user districts

for External affiliated user

  • the user must have the External/affiliated user authority in action to a register relation with the external partner/affiliation attached the the recipient (ex. CA on HF for a claim )

...

  • add HF user specific authorities

    • PortalRead that will require a link to the HF in addition to the right

  • create an HF user table (or make PHuser PH user more generic)

    • link to HF

    • link to user

  • Update the claim to take a user iso instead of a CA

  • CA table should become a view for compatibility

    • 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

  • Add village specific authorities for Enrollment support all kind of location for the user location (not only disctrict)

    • Partially done, multilevel parent to be uspported

  • 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 and change the EO village to UserVillage (or merged to Policyholder table into an External user table ? )(use normal user + location = village or disctrict

  • create a EO view for compatibility

  • Question : Should we create a contact “contact” table to have CA without user ? (could be reused fro 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 accesss access CI must be “deleted“ too (flag deleted to True)

...

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

Full admin

Every system need super admin to solve issues experienced by other user

...

  • add a “is_admin“ to interactive user

  • if “is_admin“ is true all “check permission“ must return True

  • only a super admin can define a user a super admin

  • block Technical user

  • Allow user to with is_admin = True to connect to django admin

  • nice to have: impersonation of super admin as other user - all restriction of the selected user should be applied

    • add a impersonator token + possibility to generate another user token to do the impersonation