2020-11-19 : Developer training material Q&A

Although no question list was submitted for the preparation of the workshop and, consequently, the foreseen workshop was cancelled.

However an “informal list of questions” were answered during a 1h prolongation at the end of the 19/11/2020 weekly meeting (list here below).

As of the end of the session, all (current) questions were answered. Next step is to (eventually) pile up additional questions until reaching a threshold that would make a second session efficient.

openIMIS error handling (mainly backend)

General question was raised on error handling in openIMIS.

The given answer was to describe error handling at high level, and according to the various ‘dimensions’ of it:

• as a client app connecting to openIMIS or ‘within’ openIMIS

• types of errors: from connectivity error, exchanged data format errors and ‘business logic' error

• and the various techniques used: HTTP standard error (500, 401,…), graphql/FHIR standard error response… and mutation error status code (and detail)

openIMIS task scheduling

Quick recap of django apscheduler module (as described in backend video 3 cfr. https://openimis.atlassian.net/wiki/spaces/OP/pages/1277493249 )

openIMIS dates management (backend and frontend)

openIMIS has been made from start to support distinct calendars (as the Nepali one … but actually possibly any other)… so date ‘processing’ in openIMIS is not “usual”/”standard”.

Response went into the various aspects of having an “wrapping layer” (in the core modules) on the calendar and the architectural decisions that were made for it to work:

• database keeps Gregorian calendar dates

• business models use an openIMIS django custom field (provided in the core) to ‘map’ the read Gregorian date to a calendar-specific date (and by default it is a Gregorian date too).

• all calculations (like “add 1 year/month” to the date for policy expiry to “diff between two dates” to get the age of the insuree,…) are made via the activated calendar in the core (and by default the Gregorian one)… so that modules don’t have to cope with this.

• from backend to outside, date is again transformed back into a Gregorian date (so in the GraphQL, FHIR API, ISO --gregorian-- dates are exchanged)

• in the frontend, the cor provides (publishes) a “DatePicker” that is also a wrap around either the Material-ui one (based on Gregorian calendar) or a found opensource library (for the Nepali one)

openIMIS access rights (backend and frontend)

openIMIS is (re)using (or “plugged onto”) the legacy access (rights, profiles, roles) custom definition (database tables).

• on the backend, “legacy” rights have been wrapped into django standard permissions mechanism… so that modules can check rights, the django standard way (and, for new modules, django standard access rights management can be used)

• on the frontend, all modules rely on the presence of the “user” (with its rights) loaded by the core into the redux state at the (React) application bootstrap

openIMIS Insuree Picker

As an example of module contribution, the 2 versions (one based on CHFID only - as in claim- , one with lastname, other names search capability - as in policy-) of the insuree picker from insuree module have been detailed… including the way to expose the ‘projection’ (allowing to modules like claim to query the necessary details of an insuree without actually needing to know them)

openIMIS PK (auto-fields) vs. UUID fields

Today, in openIMIS, all major entities (like insurees, claims, policies,…) have an ‘historical PK' as an auto-increment integer… and an additional “UUID” unique field. This makes things rather complex (especially for the “relations” aka foreign keys).

This decision was made independently from the legacy/new architecture and find its origin back in the audit of the (legacy) code made in 2017-2018: for security reason, it is advisable not to have sequence in the IDs (especially those that appear in the URLs)… so that ‘malicious users’ are not able to guess (attempt to access) the ‘next’ claim…

Ideally, we must clean the ‘old’ (auto-increment) PK and only rely on the ‘new’ (UUID) unique columns. However this requires a major refactoring, with a huge risk of regression, so the (temporary until legacy code full decomissioned ?) solution was to use the UUIDs in all URLs (but keep the FKs/django models defined on the ‘old’ auto-increment PKs).

SwissTPH explained that they requested to have the newly developed modules to use the UUID directly as primary keys. They are native MS SQL or Postgres types, not strings so are efficient.