Hi @Tangy thank you for the interesting question! As @Barnabas_Akumba said there are many ways that this could be handled. It might help a lot more if you add more description such as the use case, and whether this is on tracker or aggregate?
Hi @Gassim it is a tracker for child care and protection services. Social workers register cases reported to them on the system for instance of a child who might be experiencing gender based violence and then track the processes and the services given to the client thereof and any referral if need be. Thus, for confidentiality purposes a fellow social worker is not permitted to view what another social worker has registered and the services given to the child she/he has registered unless of course given the permission to do so.
If I as a social worker registered a child, my colleague should not be able to view or edit the children that I have registered.
Thank you for the ping @Tangy! Yes, I hope we get other responses from the community (@Barnabas_Akumba and other experts). I asked for advice about your use case and it seems like it needs one to be a bit creative and a lot of work to configure and maintain.
One suggestion would require that only one program is used in the instance and this is because when configuring the program it will use the global OU hierarchy since the data access rights are based on both, OUs and user groups.
The case here is that you can create one for each worker in a facility a child OU to that facility. “The program set at RESTRICTED would then ensure only that OU or worker has access to the TEI.” For example, if we are working in the “CoP Facility” Pecky will be assigned one OU_Pecky and Gassim will be assigned OU_Gassim where both OU_Pecky and OU_Gassim are children OUs of the “CoP Facility”
I was thinking if Level 1 has two main child OUs (one which will be the main for all the facilities that will work in the way explain above) and the other OU used as usual, but I’m not sure if that works perfectly.