DOCSEARCHbyAlgolia
Submit Docs

DHIS2 Core

repository·master·Indexed 43 days ago

https://github.com/dhis2/dhis2-core

A flexible information system for data capture, management, validation, analytics, and visualization. It provides a RESTful Web API for metadata and data management and includes core services for analytics, security, and tracker functionality.

Tokens
23.6K
Snippets
54
Records
148
Agent score
55%

What's inside DHIS2

  3. Manage DHIS2 Datastore namespaces and keys

    master

    The Datastore API allows you to store and retrieve arbitrary JSON data organized by namespaces and keys.

    Common parameters used across Datastore endpoints:

    • namespace: The name of the specific namespace.
    • key: The name of the specific key within a namespace.

    Available operations include:

    • Listing available namespaces.
    • Listing all keys within a namespace.
    • Searching for entries in a namespace using criteria.
    • Adding, updating, or deleting specific key-value pairs.
    • Deleting an entire namespace and all its contents.
    • Retrieving JSON values or metadata for specific keys.

  4. Filter Tracked Entities by Organisation Unit and Mode

    master

    When requesting tracked entities, you can scope the results by organisation units using the orgUnits and orgUnitMode parameters. Ownership is determined by the provided program if specified; otherwise, the registration organisation unit is used.

    orgUnits parameter

    Provide a comma-separated list of UIDs: <orgUnit1-uid>[,<orgUnit2-uid>...].

    orgUnitMode parameter

    Controls how the orgUnits parameter is interpreted:

    • SELECTED (default): Returns entities owned by the specified orgUnits.
    • CHILDREN: Returns entities owned by the specified orgUnits or their direct children.
    • DESCENDANTS: Returns entities owned by the specified orgUnits or any of their descendants.
    • ALL: Returns all tracked entities regardless of ownership (requires Search Tracked entity in all org units authority). The orgUnits parameter is not allowed in this mode.
    • ACCESSIBLE: Returns entities owned by any organisation unit in the user's capture scope. The orgUnits parameter is not allowed in this mode.
    • CAPTURE: Returns entities that have an enrollment organisation unit in the user's capture scope. The orgUnits parameter is not allowed in this mode.

  5. Filter Tracked Entities by Update Time

    master

    Use these parameters to retrieve entities based on when they were last modified (including changes to attributes, enrollments, events, or relationships).

    • updatedAfter: Returns entities updated after the given time (inclusive).
    • updatedBefore: Returns entities updated before the given time (inclusive).
    • updatedWithin: Returns entities updated since the given ISO-8601 duration.

  7. Filter Tracked Entities by Assigned User

    master

    Control which tracked entities are returned based on event assignments to users.

    assignedUserMode

    • ALL (default): Returns all tracked entities regardless of assignment.
    • CURRENT: Returns entities with at least one event assigned to the logged-in user.
    • ANY: Returns entities with at least one event that has an assigned user.
    • NONE: Returns entities with no events assigned to any user.
    • PROVIDED: Returns entities with events assigned to the specific users listed in assignedUsers. This mode requires the assignedUsers parameter.
    /* Example usage of PROVIDED mode */
// assignedUserMode=PROVIDED&assignedUsers=USER_UID_1,USER_UID_2

  8. Logic flow of buildEnrollmentQueryWithCte

    master

    The buildEnrollmentQueryWithCte(params) method assembles a complex SQL statement using a multi-step process:

    1. Collect CTE Definitions: Scans EventQueryParams to identify Program Indicator items or items bound to specific Program Stages that require special handling. These are stored in a CteContext.
    2. Generate CTE Filters: If items have filters (e.g., "the last event's value must be X"), a separate filter CTE is generated to handle the logic.
    3. Append the CTE Clause: Aggregates all definitions from CteContext into a single WITH ... clause at the start of the query.
    4. Construct the Main SELECT: Combines standard enrollment columns (e.g., enrollmentdate, trackedentity) with derived columns from the CTEs (e.g., cteAlias.value AS column_name).
    5. FROM and JOIN Logic: References the main enrollment analytics table and appends LEFT JOIN statements for every CTE in the context.
    6. WHERE Clause: Combines base filters (date ranges, org units) with additional filters derived from the CTEs via addCteFiltersToWhereClause.
    7. Sorting and Paging: Appends ORDER BY, LIMIT, and OFFSET based on the provided parameters.

  9. How Enrollment CTE refactoring works

    master

    In DHIS2 analytics, retrieving Enrollment data often requires derived fields (counts, last recorded values) from associated Event tables. Historically, this was done using correlated subqueries in the SELECT and WHERE clauses.

    To improve performance in PostgreSQL and ensure compatibility with analytics engines like ClickHouse or Doris (which do not support referencing outer fields in subqueries), DHIS2 uses a Common Table Expression (CTE) approach.

    Instead of running a subquery for every single row, the system:

    1. Computes required aggregates or latest values upfront in independent CTEs.
    2. Uses window functions like ROW_NUMBER() OVER (PARTITION BY enrollment ORDER BY ...) within those CTEs to identify specific records (e.g., the most recent event).
    3. Joins these CTE results to the main enrollment table using LEFT JOIN on the enrollment ID.

  10. Order Tracked Entity Results

    master

    Sort the returned tracked entities using the order parameter. The format is <propertyName1:sortDirection>[,<propertyName2:sortDirection>...].

    • sortDirection is case-insensitive: asc (default) or desc.
    • You can order by attribute UIDs (this orders by the attribute's value, not the UID itself).
    • Case-sensitive property names include:
      • createdAt
      • createdAtClient
      • enrolledAt
      • inactive
      • trackedEntity
      • updatedAt
      • updatedAtClient

    By default, if no order is provided, results are ordered by newest (internal ID descending).

    order=createdAt:desc,enrolledAt:asc

  11. Filter events by organization unit and user assignment

    master

    When querying events, you can restrict results based on organization unit hierarchy and user assignment modes.

    Organization Unit Filtering

    Use orgUnit combined with orgUnitMode to define the scope:

    • orgUnitMode=SELECTED, CHILDREN, or DESCENDANTS: Requires the orgUnit parameter.
    • orgUnitMode=ALL: Returns all events regardless of ownership (requires Search Tracked entity in all org units authority).
    • orgUnitMode=ACCESSIBLE: Returns events owned by any org unit in the user's effective search scope (union of defined search scope and capture scope).
    • orgUnitMode=CAPTURE: Returns events that have an event organization unit in the user's capture scope.

    User Assignment Filtering

    Use assignedUserMode to filter by user assignment:

    • ALL (default): Returns all events.
    • CURRENT: Returns events assigned to the logged-in user.
    • ANY: Returns events assigned to any user.
    • NONE: Returns events not assigned to any user.
    • PROVIDED: Returns events assigned to specific users listed in the assignedUsers parameter (e.g., assignedUsers=user1-uid,user2-uid).

  12. Track and export test coverage via endpoint tracking

    master

    By enabling -Dtest.track_called_endpoints=true, the tests will generate a coverage.csv file. This file contains a list of tested HTTP methods and URLs, formatted as: METHOD,/path/to/endpoint,count (e.g., GET,/programs/ZShpl0NB7TL,1).

    Important: If running tests inside Docker, ensure the file is written to a mounted volume or manually copied out of the container before it is destroyed.