Skip to main content

DHIS2 vs. Generic Mode

The one switch that matters​

ADAPTER_MODE, an environment variable, is read in exactly one place: getAdapterMode()/isDhis2Mode() in src/app/config/adapter-mode.ts. Every other part of the codebase that needs to know the deployment mode calls isDhis2Mode() — never process.env.ADAPTER_MODE directly. This was a deliberate consolidation (there used to be several independent ADAPTER_MODE === 'dhis2' checks scattered around).

ADAPTER_MODE is decided once, when the application boots. There is no way to switch modes without restarting the app.

What's actually gated by it​

  • The DHIS2 organisation-units module (OrganizationUnitsModule and its HTTP client) — only registered when isDhis2Mode() is true. Outside DHIS2 mode, a NullDhis2LookupProvider DI adapter is used instead, so code that depends on the lookup interface doesn't need its own mode-checking.
  • Which auth provider is active — LocalAuthProvider vs Dhis2AuthProvider, chosen in AuthModule at module-registration time via isDhis2Mode().
  • HmisEoD's nightly cron — the legacy DHIS2 end-of-day report computation only runs in DHIS2 mode; nothing in generic mode ever reads what it would compute.
  • dhis2CategoryOptionCombo on report field definitions — nullable, not required, specifically so generic-mode deployments aren't forced to fill in a DHIS2-specific UID that means nothing to them. The DHIS2 push pipeline filters out any field with no COC before sending data.

A caveat worth knowing: a configuration key that isn't actually live​

There used to be a database configuration table key, auth.provider, that looked like it should let you switch auth strategy at runtime the same way other integration config works (see Architecture). It didn't — AuthModule decides the active provider once, at boot, via ADAPTER_MODE, and never read that database key at all. This was confirmed directly: even valid DHIS2 credentials were rejected in a real test run, because the app was still using LocalAuthProvider regardless of what the auth.provider config said. The key has since been removed from the seeded configuration; if you're wondering why deployment mode can't be changed without a restart, this is why — it's the honest current behavior, not a bug to route around.