For the complete documentation index, see llms.txt. This page is also available as Markdown.

Release Notes

Release Summary

The DIGIT HCM v1.8 release introduces a Central Instance Deployment Modelβ€”running services for multiple countries (Mozambique, Liberia, Nigeria) on a single Kubernetes cluster. Data for each country is securely isolated at both:

  • Namespace level (Kubernetes separation)

  • Database schema level (PostgreSQL schemas)

Goals:

  • Reduce ongoing maintenance

  • Standardise configurations across countries

  • Avoid duplication of services

  • Still allow country-specific customisations where required

  • Save infrastructure costs by leveraging a central instance capability

Note: This update applies only to application-facing services. Admin Console and Micro-Planning services are not included.


New Capabilities

1. Admin Console (v0.4)

  • What it is: A no-code, configurable console.

  • Purpose: Allows partners and field teams to independently design, localise, and deploy campaigns without engineering help.

2. Server-Generated Beneficiary IDs

  • What it is: Pre-generated Beneficiary IDs created on the server.

  • How it works: Synced to the app during login.

  • Benefit: Enables registry reuse across campaigns by giving each household/individual a unique ID.

3. Enumeration Tool

  • What it is: A Tool for capturing household- and individual-level data.

  • Features: Supports conditional questions and structured relationships (e.g., parent-child).

  • Purpose: Flexible community health enumeration in areas without standard formats.

4. Transit Tool

  • What it is: New "Transit Post" campaign mode.

  • Use case: For locations where pre-enumeration isn’t possible (e.g., bus stops, parks).

  • Purpose: Records aggregate counts with location details instead of individual records.

5. Attendance Proof of Work

  • What it is: QR Code Scanning for employee attendance.

  • Benefit: Improves reliability and accountability in campaign deployments where supervisor-marked attendance lacked verification.

6. Peer-to-Peer (P2P) Data Sharing

  • What it is: P2P downsync sharing between devices via Wi-Fi Direct.

  • Purpose: Enables offline data sharing to keep field work running in low/no-connectivity areas.


Enhancements

1. Centralised Multi-Tenant Deployment

  • Single Kubernetes cluster for Mozambique, Liberia, and Nigeria.

  • Common namespace: Shared core services (e.g., egov-user, workflow, egov-otp, MDMS V2).

  • Dedicated tenant namespaces: Country-specific services (e.g., Liberia HRMS, Nigeria HRMS).

2. Multi-Schema Database Support

  • Single PostgreSQL instance with separate schemas (public, liberia, nigeria).

  • Automated Flyway migration using migrate.sh for all schemas.

  • Schema lists and enablement flags are configurable via Helm & environment YAML.

3. Mobile App Endpoint Segregation

  • Separate apps per country (example: Mozambique - mz, Liberia - lb, Nigeria - ng).

  • Each app connects to tenant-specific URLs for correct routing.

4. Standardised Kafka Topic Naming

  • Tenant-prefixed format prevents collisions.

  • Example: mz-save-household-topic, lb-save-household-topic, ng-save-household-topic.

5. Helm & Configuration Improvements

  • Common values.yml for baseline DB/service settings.

  • App-specific values.yml overrides for schema/multi-schema flags.

  • Backwards-compatible for services without multi-schema needs.

6. Centralised Internal Gateway & MDMS v2

  • Internal gateway configurations are stored centrally for easier updates.

  • MDMS v2 configs consolidated per tenant for consistent metadata.

7. Shared vs. Tenant-Specific Services

  • Shared services: Household, Individual, Stock, Facility, Product, Service Request, Egov-HRMS, Project, Referral.

  • Tenant-specific services: Deployed only where needed (e.g., Liberia HRMS, Nigeria HRMS).


Technical Documents
Functional Documents
  1. Attendance Revamp

  2. Migration Guide

  3. Central Instance

  4. HCM Console Configuration

Last updated

Was this helpful?