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.