Why is This Important?

• Stops “proxy” (fake) attendance and manual tampering.

• Makes attendance more trustworthy and easy to verify.

• Keeps things simple for supervisors.

• Prepares for future features like location and time stamping.

Technical Release Highlights

What’s New?

• Tagging Employees for Better Grouping and Search

  • You can now add a “tag” (like “SHIFT”, “PROJECT”, or “SKILL”) to each attendee.

  • Tags help you organise and filter attendance records easily.

• Bulk Tag Update API

  • New API: POST /attendee/v1/_updateTag

  • Lets you update tags for many attendees at once.

  • Validates input to make sure tags and attendees are correct.

• Tag Search

  • You can now search for attendees using tags in /attendee/v1/_search.

  • Supports searching with one or more tags.

• Database Updates

  • A new “tag” column was added to the attendance table for fast searching.

  • Database and config updated to handle tags in all attendance actions.

• Code Improvements

  • Added error messages for invalid tags and mismatches.

  • Cleaned up unused code.

  • Updated version to 1.3.0 to include these features.

Summary Table

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

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).

Document Resources & Links

• Open the health-campaign-config repository.

• Merge the following PR changes into the appropriate branch: 🔗 HCM v1.8 Config Changes

• After merging, apply the Project Factory V2 API Persister changes: 🔗 Project-factory Persister Changes

APK Upgrade Guide

Below are the steps to upgrade from v1.7.0 → v0.2.0.

Commit 4