Cht-core: As a data entry clerk I want to access, create, edit people in a place that I can access, and report about them, but not see any of the reports created by others for those contacts.

[senseibara]

Is your feature request related to a problem? Please describe.
Currently it doesn't seem possible to limit the replication depth of a user in a way we only have access to contacts of the level below and not to the reports that are submitted on that level below.

Describe the solution you'd like
user 1 : health_center level ( primary contact )
user 2 : clinic level (primary contact )

Requirement 1 : User 1 should be able to access create and edit people in user's 2 place and be able to submit a report about them. Those reports and contacts should get replicated and accessible to user 2

Requirement 2 : Reports that User 2 will submit on contacts he have access to should not be replicated to user 1 unless the report include a true needs_signoff

Describe alternatives you've considered
Right now we are applying a replication depth of 3 for User 1 for him to have requirement 1 but he is seeing all reports that user 2 is submitting which is not what we want.

Additional context

[garethbowen]

@senseibara Can you provide more information about _why_ user 1 shouldn't see these reports? Do they contain sensitive health information, is it a performance issue, or is user 1 simply not interested in the reports?

[senseibara]

@garethbowen for now this is just for us to anticipate performance issues. User 2 might generate up to 18 reports per workflow completed per contact, also we do not expect user 1 to be interested in the reports.

[MaxDiz]

Relevant slack conversation: https://medic.slack.com/archives/C3TJFFKK7/p1587582129057200

Adding to v3.10 for MSF-Niger project covid response, and Palladium HIV interventions. Before starting, review prototype feedback with @kennsippell and @senseibara

[MaxDiz]

This issue was de-prioritized for its initial intended deployment to MSF-Niger. It may still be relevant for Palladium. I will follow-up in slack with @derickl and @kennsippell to discuss.

[MaxDiz]

This issue remains a priority for v3.10. Relevant discussion here: https://medic.slack.com/archives/C3TJFFKK7/p1588706985024100. @derickl please add Palladium feedback as well, so we can make sure we are addressing all related needs in this ticket.

[kennsippell]

User 1 should be able to access create and edit people in user's 2 place and be able to submit a report about them. Those reports and contacts should get replicated and accessible to user 2

@senseibara, can you clarify this comment?

be able to submit a report about them

Who exactly is "them" in that comment. Are you saying User 1 should be able to submit a report about a person in user 2's place but not see any of that person's other reports?

[senseibara]

That's correct. Right now with Replication depth 1, User 1 will see the place of user 2 but not people/persons created on that place. Ideally we should be able to see these people/persons and submit a report about them that will get replicated to user 2 account, but without seeing reports submitted by user 2 for these people/persons at his level.

[kennsippell]

As @senseibara describes it, this issue is useful for addressing the scaling needs of our MSF-Niger covid response and therefore remaining in 3.10.

It would be nice to have somebody confirm the feasibility of this feature request from the product perspective. How well does it generalise? What would the config look like?

[dianabarsan]

@kennsippell

scaling needs of our MSF-Niger

Are we discussing device-level scaling or server-level scaling? Is it so User1 doesn't generate tasks for User2's reports? ( we don't pass the user object to tasks, right? we have no way of filtering tasks by the user's roles. )

Because of how we do doc authorization, off the top of my head, we'd still need to get the list of all reports submitted under every level the user has access to, just to filter "some" of them to the ones that the user himself has created.

[kennsippell]

@dianabarsan

we don't pass the user object to tasks, right? we have no way of filtering tasks by the user's roles

Unsure if this is what you're asking, but we pass the user's contact as a global into nools. So tasks can look at the contact associated to the user, but not the user doc.

This is for device-level scaling. @senseibara Can you work with Diana to clarify needs?

[dianabarsan]

I went with adding a new option to replication_depth called report_depth (final name is TBD) which works in conjuction with the already existent depth (see https://github.com/medic/medic-docs/blob/54c9c40c4a2a3c7cc2d0449e05a14ccf3574a5a1/configuration/replication.md#depth)
Ex:

{
  "replication_depth": [
    { "role": "district_manager", "depth": 1 },
    { "role": "national_manager", "depth": 2, "report_depth": 1 }
  ]
}

In terms of what is visible, for example for
{ "role": "national_manager", "depth": 2, "report_depth": 1 }, a hierarchy like district (0) > center (1) > clinic (2) > area (3) and a supervisor at district level.

This supervisor would see district, center and clinic, along with any other person that belongs to district and center.
The supervisor would not see any person belonging to clinic and no areas.
The report_depth of 1, in this case, would mean that this supervisor can only see reports of district (0) and center (1) level, and no reports at clinic level, unless they're submitted by himself!

If you set report_depth to be larger than depth, it would have no effect.
Also, without the depth setting, it would have no effect ({ "role": "district_manager", "report_depth": 1 } is ignored)

Reports with needs_signoff work like before.

Does that work for you, @senseibara ?

[senseibara]

hey Diana, thanks you first of all this looks really great.
Will it be possible also to have a 'report_depth' : 0 ? That would mean the supervisor can only see reports of district(0) but won't see reports submitted by center(1) unless those reports are submitted by himself.

[dianabarsan]

Will it be possible also to have a 'report_depth' : 0 ?

Yes, it's possible.

[senseibara]

Perfect for me then, nothing else to add on my side. Thank you !

[garethbowen]

Ready for AT in 6352-adds-report-replication-depth, documentation.

[ngaruko]

LGTM .
Did you want to have a second look @senseibara

[dianabarsan]

@senseibara are you interested to AT this before it gets merged?

[senseibara]

sorry @ngaruko @dianabarsan for my late answer,
I can try this out monday and revert to you( hoping that's a fine turnaround )

[senseibara]

@ngaruko @dianabarsan , i tested a few scenarios and it looks really great to me ! nice work @dianabarsan.

[dianabarsan]

Merged into master.