In DHIS2 v42 Capture, I have a user with approximately 5300 facility organisation units assigned in organisationUnits.
dataViewOrganisationUnits and teiSearchOrganisationUnits are assigned to the root organisation unit (Egypt).
The user is intentionally not assigned to the root organisation unit in organisationUnits because the requirement is to show only the assigned facilities.
Observed behavior:
Firefox eventually loads the organisation units, but after a long delay.
Chrome shows: “Error: An unknown network error occurred”
The failing requests are:
GET /api/42/organisationUnits/{uid}?fields=displayName,path,id
The organisation unit IDs exist and can be retrieved successfully through the API.
Has anyone experienced limitations or performance issues in Capture when a user is directly assigned several thousand organisation units?
I also found Jira DHIS2-19164 describing similar performance issues with large numbers of organisation units, although it was reported for the Data Entry app.
Sorry to hear you’re facing this issue. We need to make sure the user has these OUs assigned in both the Users app as well as the Program metadata configuration, could you please double check that both are assigned?
I have verified that the OUs are assigned in both the Users app and the Program configuration. I have attached a GIF demonstrating this.
The issue only occurs when the user is assigned a large number of OUs. However, my admin account has access to all organisation units, and this issue does not occur.
This proves that the issue is simple. We need to figure out what’s the sharing setting that’s missing from those accounts. If it’s not occurring in the admin account then it’s probably an authority/assigning issue.
I have already verified all sharing settings. The issue only occurs when the user is assigned ~5300 organisation units. Firefox eventually loads them, while Chrome fails with ERR_INSUFFICIENT_RESOURCES. This appears related to the number of assigned organisation units rather than access settings.
Could you explain what you mean by “The issue only occurs when the user is assigned a large number of OUs. However, my admin account has access to all organisation units, and this issue does not occur.”
Have you assigned your user the root orgunit or have you assigned each and every individual orgunit per your screenshot?
The root cause of this is that the client is generating an extremely long URL. Different browsers and infrastructure may error out on very long URLs. That is likely why it works in one browser and not the other.
The affected user was assigned ~5,272 organisation units individually, not the root org unit.
The issue occurs in Chrome, while Firefox eventually loads after a delay.
I have created Jira ticket DHIS2-21855, which is currently under investigation.
The fundamental issue is that Firefox allows much longer URL lengths than Chrome. This may also be affected by infrastructure between the browser and server.
Ultimately, it’s a client problem. The client is attempting to make a request with those many thousands of assigned organization units which is far too large. Recommend URL lengths are less than 2048 characters, and with many thousands of orgunits (each with and 11 character UID) you will quickly exceed this limit.
This is not a problem only here but can also easily be reproduced in the data visualization app by selecting a huge number of data elements.
It’s a bug for sure but it can be easily reproduced in other apps as well.
I am however skeptical of your approach. Surely there is a better way to do this than to assign thousands of individual organization unit to each user?
This is a real deployment scenario. The CCE administrator needs access to all facilities within their supply chain management scope, resulting in approximately 5,272 assigned organisation units.
It’s interesting to see why your admin account isn’t facing this issue while the other account is. Are you using Firefox and the other user Chrome? Or could this be something else?
I’m using Chrome for both accounts; Firefox was only used for testing. The admin has access through the root OU, while the affected account has 5,272 individual OUs assigned without the governorate roots. This may explain the difference.
Thanks!
