Each module (backend or frontend) offers configuration options:

• enabled/disable contributions (e.g. display the family data on the enquiry dialog)

• parameters values (e.g. the fhir code corresponding to imis passport type)

• console-enabled configuration (like report templates for report module)

Each module lists its configuration option in their README.md file of their source repository (i.e. https://github.com/openimis)

In order to change the default value of any module, the openimis backend core module

exposes the ModuleConfiguration entitity in the django admin console, on the backend service (meant to be protected from internet public access).

Login URL is /iapi/admin, you need to be (django) superuser to access the management console:

Open

Authentication and Authorization

This section is dedicated to django-managed user management.

In current version, user management is “bridged” to legacy user (roles, rights,…) definitions: django is configured to trust REMOTE_USERs authenticated by legacy openIMIS and auto-provision them as django (session) users.

The only necessary (user) group is automatically created at application startup (if not already there) and has the only necessary django permission: “Can view user”

Core Admin Contribution

The openIMIS backend core module provides 3 entities managed via the admin console:

Module configurations

Each module (backend and frontend) foresees configuration options which can be controlled (defaults overwritten) via the corresponding ModuleConfiguration entity.

WARNING: The backend ModulConfiguration entry is loaded by its module name (claim, api_fhir,…), while the frontend module ModulConfiguration entry is loaded by its module name, with the fe- prefix (fe-claim, fe-insuree,…)

Modules list their configuration options in the README.md file.

Example (from openimis-fe-claim_js README.md):

Open

The default rows per page options in the claim filter is [10, 20, 50, 100]:

With the following fe-claim ModuleConfiguration, one can change it to other values:

WARNING:

Because (backend) modules may contain sensitive information (credentials to other backends' APIs,…) one must explicitly check the ‘is exposed’ box to make the configuration accessible from moduleConfigurations GraphQL query endpoint (all others ModuleConfiguration entries are filtered from API access).

That endpoint is called (only) once at (frontend) application startup (in the browser), for any configuration change to be applied, users have to logout/login.

Backend modules configurations are not supposed to be published via the GraphQL API. They are loaded at django application startup. As a consequence, any (backend) configuration change requires a django app (service) restart to be applied.

Field controls

This entity allows to control wherever the frontend should (or not) display the various fields, …

To enable this feature, frontend modules have to wrap the form fields within the ControlledField react component (provided in frontend core module) and identify the controlled field with the module it belongs and an identifier.

Note: all table using the @openimis/fe-core Table generic component also automatically receive the controlled field mechanism for their columns)

Field Example: (from fe-claim module, ClaimMasterPanel.js component):

With this setup, if the fe-claim Module configuration is activated (and exposed), one can hide the Guarantee Id field from the claim form (master panel section) adding the following entry in the Field controls:

With this setup, the Guarantee ID field is not displayed anymore:

Table Example (from fe-claim module, ClaimSearcher.js component):

[…]

With this setup, if the fe-claim Module configuration is activated (and exposed), one can hide the Insuree column of the result table of the claim searcher adding the following entry in the Field controls:

Technical users

Depending on the gateway configuration, APIs (FHIR and/or GraphQL) may be exposed without (legacy) openIMIS authentication. To enable such access, the gateway must provide a (SSO, certificate-based, basic auth,…) authentication mechanims and authenticated users must be registered as TechnicalUsers.

Notes:

The (django) super user is also a “TechnicalUser”, with “superuser” flag:

All others modules Admin Contributions

Each (backend) module is allowed to register (some of) its entities to be exposed in django admin console. This allow module implementers to extends the (basic) default configuration in ModuleConfiguration.

Example: the report (backend) module provides a mean to overwrite any default report template (provided in module source code).

The openimis-be-claim_py/claim/reports/claim.py provides the default (Report Bro) template for the claim prints (pdf).

However, while calling the report (backend module), the claim module provides a template identification used by the report module to detect any configured replacement template. That report identification is provided in the module README.md file:

So the provided (default) template can be replaced via: