Restrict data collectors viewing event data (submissions) on the same event program and OU

Hi all,
We have two groups of data collectors. We want them to use the same event program in the same OUs, but we do not want them to be able to see each other’s submissions. With an event program, is there a way to do that? Could one group not see any data at all after they’ve submitted it? (that would be fine but I’m not sure how to do that) Could a category combination work (preventing one of the cat option combos from viewing the other catoption combos data)?
Thanks for any ideas!

1 Like

And follow up question - can we hide a section of the event form from a certain user group? I know you can hide a tracker program stage but I haven’t done this with an event program section. I used a program role with d2:hasUserRole(‘uid of user role’) and action “Hide section: [section I want hidden]” but the section still appears in the event form, when I test it using the credentials of a person with restricted user role.

First thoughts on the first scenario:

  1. Could roll it up to the same OU, and disaggregate to group specific OUs as children within
  2. Category Option sharing distinctions; basically a Category with two Category Options, each shared with one user group. You’d need for the Category Option to not have public view access, and obviously give each user group data capture and metadata view access. They’d still be able to see data entered in event reports/data visualizer, however (and the API), but not if the category was brought in as a filter/dimension.
  3. A cloned program with distinct sharing settings (although I recognize that breaks a premise in your scenario)

Interested to hear how you tackle it!

2 Likes

Thanks Matthew! I think we’ll probably go for option 3. We haven’t been able to figure out how to make 2 work. We’ve tested but both groups can still see each other’s data in the form and in analytics, and hiding a section for the user group seems to be broken. Maybe I’m missing something because what you described seems possible!! Thanks again!

@Natalie_Tibbels interesting on the user group condition for a program rule action not working–haven’t tested that out personally but was hoping to in the coming weeks.

Back to the CategoryOption side—I’m surprised about the ability to see other’s data in the form. If they don’t have access to the CategoryOption, then they shouldn’t be able to see data with that CategoryOption selected. In analytics, though, I agree all data would be visible unless the category was brought into the object.

I think the user group program rule issue is mentioned here (me again):

and a jira issue: [DHIS2-14878] - Jira

Though it may be an issue with my configuration and not a bug… happy to be updated if people figure that out!

On the CategoryOption, let me check in and see if we can avoid giving one of the groups access to analytics. I think you’re right that they wouldn’t see the entries from the other catoption within the capture app. What do you mean “unless the category was brought into the object”?

Really just mean that if someone has access to the category, but only 1 of 2 Category Options, if the Category is included as a filter/series/whatever in the object, then there would be clear filtering of the data in the way you want. But if you don’t have the Category brought into the section, all data would appear; so if a user went in an created an object, they’d have to filter the data themselves by bringing in the Category, which sounds pretty far from ideal.

The more I think about this, the more I personally like the OU disaggregation; is it possible to put two children below the OU they are reporting at, and give entry users very specific access?

1 Like