Hi all,
I am facing an issue with a tracker program - we have users who are entering data for a bunch of TEIs in multiple OUs all at once. We realized that new program stages for existing TEIs follow the OU you are clicked on when you search, not the OU that the client is belongs to. At first I thought this was a glitch, but I’m thinking that it’s part of the functionality of tracker to be able to follow people through experiences in multiple OUs. But it has led to data quality issues since local data collectors are not verifying the OU when they add the program stage. (lesson learned…) The confusing part I think for the data collectors is that they are adding data from multiple OUs at the same time, so they are just searching, the search results display the client ID with the enrollment OU, so they are just assuming all is well with the new stage going with that OU.
I’m wondering what others think of having an OU field when you add a program stage to an existing TEI, that defaults perhaps to the OU from the search or to the OU where they were enrolled so most of the time you wouldn’t have to change it, but it would be a verification step that you are putting the stage in the OU you want. Have others had this issue?
~Natalie
Hi @Natalie_Tibbels,
We are exactly experiencing the same challenge and same scenario (users with both search and capture OU for different facilities adding multiple TEI’s at once). As you I also thought that this was a bug but then realized that this might be the expected functionality.
Another challenge we had is that the user wanted to update the TEI’s attributes from an OU that has not ownership of the TEI (although the user as said have Capture and Search permissions for that TEI). Fortunately, this has been recently hadled: [DHIS2-7094] - Jira
We have proposed the following functionallity in Jira,
https://jira.dhis2.org/browse/DHIS2-5285
Do you think this proposal will also work for your case? just to see if I understand well the solution you propose. I have tried to made a proposal that could extend to other scenarios so I will be more than happy to have your input there.
Yours,
Eric
We had similar issues as what you are describing. And then this particular issue, that they inadvertently added program stages in the wrong OU because of what they happened to click into for the first TEI they were updating. I think something like what you’ve proposed (an alert) would be helpful. Also perhaps adding a step to select (or verify the default) OU when adding a new program stage that is different from the enrollment. Perhaps that could be a setting the admin could choose, whether to require OU verification for program stages - because I’m sure for many programs it’s not an issue and would be an extra step for data capture. Or it may be a program rule I can set - thanks for the nudge to look into it more!