fix: apply org unit hierarchy in event and enrollment pivot tables - #1846
Open
HendrikThePendric wants to merge 6 commits into
Open
HendrikThePendric wants to merge 6 commits into
HendrikThePendric wants to merge 6 commits into
Conversation
HendrikThePendric
marked this pull request as draft
September 16, 2026 14:18
3 tasks
HendrikThePendric
changed the title
HendrikThePendric
force-pushed
the
fix/pt-engine-handle-prefixed-ou-dimensions-DHIS2-22094
branch
from
September 17, 2026 11:43
4eb00c0 to
ebb0975
Compare
`getAggregate` went through `fetch`, which issues one request for data and metaData together. `get` issues two in parallel — one with `skipMeta=true`, one with `skipData=true` and `includeMetadataDetails=true` — and merges them. It is what `analytics.aggregate.get` already does and what data-visualizer-app uses. The metaData request is what makes `PivotTableEngine.applyHierarchy` work: without `includeMetadataDetails` a `metaData.items` entry carries only a name, so the org unit ids it reads from `item.uid` are all undefined. Splitting also routes the request through `analyticsDataQuery`, which sorts dimensions and items so that layouts differing only in order share a cache entry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sorting rewrites `itemIds`, which the row lookup resolves data rows through. The characteristic failure is a table with correct headers and an entirely empty value grid, which the hierarchy assertions alone do not catch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
HendrikThePendric
force-pushed
the
fix/pt-engine-handle-prefixed-ou-dimensions-DHIS2-22094
branch
from
September 17, 2026 13:01
ebb0975 to
05ade2f
Compare
A backend that returns no hierarchy for the requested dimension still sends the key as an empty object, which passes the truthiness guard and lets applyHierarchy run. Rows must keep their order and their values. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements DHIS2-22094
Description
"Display organisation unit hierarchy" has no effect on event and enrollment pivot tables. Two things in this repo stand in the way.
The org unit dimension was looked up by literal key
applyHierarchywas reached throughallByDimension['ou'], which never matches a stage-qualified dimension (<stageId>.ou) and matches at most one org unit dimension per layout. It now matches any org unit dimension: bydimensionTypewhere the response provides one, by unqualified dimension id otherwise. The fallback is needed because the dimension descriptor carries no type — measured against the aggregate endpoint,metaData.items['<stageId>.ou']is{"name": "Organisation unit"}and nothing more.The aggregate request did not ask for metadata details
applyHierarchyreads each org unit's id fromitem.uid. That field only exists when the request setsincludeMetadataDetails=true, andgetAggregatewent throughfetch, which does not set it. Without it every id isundefined, the row lookup breaks, and the table renders with correct headers over an entirely empty value grid.getAggregatenow goes throughget, which issues the data and metaData requests in parallel —skipMeta=trueon one,skipData=trueplusincludeMetadataDetails=trueon the other — and merges the responses. This is whatanalytics.aggregate.getalready does and what data-visualizer-app uses; DV is why the hierarchy works there and not here.Verified against a live instance that merging the two responses reproduces the combined one exactly — identical headers, rows, width, height and dimension order — plus
ouNameHierarchyanduidon the items.Splitting also routes the request through
analyticsDataQuery, which sorts dimensions and items so that layouts differing only in order share a cache entry (DHIS2-17861). That sorting lives inside the query definition and is not reachable from the request builder.Only
getAggregatechanges —getQuerystill goes throughfetch, so line listing keeps its single request per page — and its one consumer across the dhis2 org, event-visualizer-app'suse-pivot-table-analytics-data.ts, needs no change because the merged response keeps the same shape.Dependency chain
ou(#25259)showHierarchy=trueon pivot requestsEnrollment pivots need 2 + 3 — they already send a bare
ou.Event pivots need all three; without 1 the backend returns no hierarchy to apply.
Verified end to end in event-visualizer-app with this branch pinned — see the "How to verify" section of #384.
🤖 Generated with Claude Code | Edited by @HendrikThePendric