I am currently working on a Tracker program in DHIS2 version 2.38, and I would like to restrict the access to the list of records so that each user can only see the cases they have entered, even though all users have access to the same organisation unit.
I believe currently it is not possible. At least if we had a built in variable such as V(current_user), you could create a DE/TEA where the current user_UID could be stored initially with the PR, and then checked/compared by the other PR and take an action. Here we have another problem: we can’t hide the stage by PR if there is any data entered. So it will be challenging to hide stages for the users in current situation.
I believe this functionality could be really useful.
Hi @Ulanbek
Thank you for your prompt and detailed response. I truly appreciate your insights on this matter. I agree with you; having such a built-in variable would indeed be very useful and could open up more possibilities for managing user-specific actions within the program.
Thanks @elmoujarrade ! As @Ulanbek mentioned, it’s not possible to restrict the visibility of the enrollment only to the individual data entry user who entered TEIs.
I’m thinking in such restricted environment, what if each data entry user has their own tracker program? This way you’d be able to achieve the restriction mentioned above where the data entry user can only see entries by one’s account only.
I received a team from one of my colleagues that it might not be a good idea to create all the several program as it might cause challenges when the data is to be analyzed by those in the above OUs.
In fact, it does seem like others have included this request before, so I’ll be looking for the similar requests in the community to share with the team. Other community members are welcome to add their input here as well.
If I remember correctly, in one of those community posts, it was suggested to create a sub OU for each data entry (maybe a better suggestion that the program for each user )… would that work? @elmoujarrade , maybe this post will be helpful if you choose this path: Best approach for OUs where CHWs come and go - #2 by Jim_Grace