...
Quick recap of django apscheduler module (as described in backend video 3 cfr. Developer starting kit )
openIMIS dates management (backend and frontend)
...
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 beteen 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)
...
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.