DHIS2-16349 still present in 2.42.4.1 — Non-super user gets empty results in Line Listing and Event Reports for current month (Tracker program with Category Combo)

DHIS2 Version: 2.42.4.1

Description:

We are experiencing what appears to be a remaining edge case of DHIS2-16349 where a non-super user cannot see current month data in Line Listing and Event Reports apps, while a super user can see all data without issues.

Setup:

  • Tracker program with a category combination assigned this month
  • All historical events updated with new AOC/COC
  • Full analytics export performed after adding the category combo
  • No analytics dimension restrictions applied to the user
  • No Program Indicators used in the report
  • Output type: Event

Behavior:

  • Non-super user: Cannot see current month data. Previous months are visible. Both Line Listing and Event Reports affected.
  • Super user: Can see all data including current month.

API Evidence:

The API response for the non-super user clearly shows the category (PM3CIs2ibmr) being added to the dimensions — exactly the pattern described in DHIS2-16349:

"dimensions": {
"pe": [],
"ou": ["oqiVr89BfVv"],
"PM3CIs2ibmr": [
"VpyaZTB78Lg",
"tqJONg76WpJ"
]
}

And the result is empty:

"rows": [],
"height": 0

Expected Behavior:

Non-super user should see current month data in Line Listing and Event Reports after a full analytics export, without the category being incorrectly injected into the query dimensions.

Reference: DHIS2-16349

P.S. An additional observation that may help diagnose the issue further: the affected non-super user can successfully see enrollment data for the current month, but cannot see event data. This suggests the problem may be specifically in how the event analytics table (analytics_event_<uid>) handles the new category combo column for non-super users, while the enrollment analytics table (analytics_enrollment_<uid>) appears to be correctly built. This is particularly interesting given that DHIS2-16349 was originally reported as an enrollment-only issue, but in our case the situation appears to be reversed.

Thanks for reporting this @m.siusko ! Looks like a good addition to the ticket you referenced (DHIS2-16349). I’ve added a comment to the ticket and triaged again to get the team’s attention: Jira