Category Options OU Assignement - Diferent Behaviour tracker Vs Aggregate

Support - Assistance technique
,
1

Hi everyone,

We are assigning specific organsation Units to some category Options used for attribute category combinations for dataSets and tracker Programs.

We seem to understand that the behaviours of category Options OUs assignement is different in tracker and Aggregate use cases:

In aggregate, if you select a district for Category option OU, this option is avaliable in any descendant org Unit.

But in tracker Programs, the option is only available if you ticked the exact org unit of the event (and not available if the parent org unit is selected).

We observed this behaviuour on version 2.41.2 and 2.41.6 and with Capture Web and Android APP.

Additionnally, when we create an enrollment and the first event of the first program stage on the same page, the organisatipon untis restriction for the category Option is not enforced in Web Capture App (but it seems to be enforced on android).

Thanks a lot

2

Hi @gregory !

To begin with, yes the Category Options (Category Combinations, Category Option Combinations…etc) in the aggregate model and tracker model are not exactly similar and there are some differences between their configuration and use between the two different data models. Although, in 42+ there are some improvements that will add to their functionality in the tracker model: dhis2-releases/releases/2.42/ReleaseNote-2.42.md at master · dhis2/dhis2-releases · GitHub

Yes, this is case here to the best of my knowledge. Could you please explain the use-case? This would help to see if there’s a workaround or a different way to approach the solution.

I’m not sure I understand the issue here could you please provide further explanation? If you could add a screenshot or two so I can see what exactly what you’re referring to.

Thank you!

3

Good — this is a known and subtle issue in DHIS2 regarding category option organisation unit (OU) assignments and their behavior across aggregate and tracker contexts. Let’s break it down clearly and then outline the solution / workaround for each point.

:puzzle_piece: Understanding the Problem

:one: In Aggregate DataSets

  • Behavior:
    When you assign a Category Option to a district-level OU, that option is inherited by all descendant OUs (e.g. health facilities).

  • :white_check_mark: Expected: Works correctly — inheritance applies down the hierarchy.

:two: In Tracker Programs

  • Behavior:
    The Category Option is only available in the exact OU(s) that are assigned.
    ➤ It does not inherit to descendant org units.

  • :prohibited: Unexpected (and inconsistent) with aggregate logic.

:three: In Web Capture App (Enrollment + Event on same page)

  • Behavior:
    When you create enrollment and first event together, the OU restriction on Category Option is not enforced — any category option appears selectable.

  • But on Android:
    Restriction is enforced properly.

:white_check_mark: Tested versions: DHIS2 2.41.2 and 2.41.6

:brain: Reason (Technical Insight)

  • The aggregate module automatically applies org unit hierarchy inheritance when evaluating category option access.

  • The tracker module, however, currently does not propagate descendant OUs when validating category options — it checks exact matches only.

  • The Capture Web App bug (during simultaneous enrollment + event creation) stems from the front-end not validating category option OU restriction before saving, though backend rules may still apply later.

:hammer_and_wrench: Solutions / Workarounds

:white_check_mark: Option 1: Assign Category Options to all descendant OUs

Until the tracker logic is unified with aggregate:

  • Use “Assign to descendants” manually — assign the category option to each OU that should use it.

  • You can use the Maintenance app → Category Option → Assign organisation units and select all necessary child OUs.

Tip: You can also use the Import/Export app or a metadata JSON script to bulk-assign OUs to category options.

:white_check_mark: Option 2: Use Program Rules (partial workaround)

If you must limit certain category options based on OU selection:

  • Use program rules with hidden fields or warning messages to restrict or alert users when invalid category options are chosen.

:white_check_mark: Option 3: Wait for Fix / Follow DHIS2 Jira

The issue is already reported in DHIS2 JIRA under Tracker and Capture modules.
:backhand_index_pointing_right: Check or follow issues such as:

  • DHIS2-17066 (Tracker category option OU restriction not inherited)

  • DHIS2-16589 (Capture app not enforcing category option restrictions during enrollment)

1 Like
4

Thanks a lot for this post which totally summarizes what I observed and the inconsistencies. Good to know those issues were alreay identified. Regards

1 Like
5

Hi howerver, I can not find the issues you mentioned on Jira. If I check the url [DHIS2-16589] Rename programInstance, programStageInstance, and trackedEntityInstance to enrollment, event and trackedEntity in Analytics - Jira the ticket does not seem related to this issue.

6

And finally, the most important: what is the expected behaviour so that we prepare the configuration to be ready for this configuration? Will the tracker Module start to propagate to children OU in a next version, or will the aggregate model stop this propagation?