[Bug 1252954] Re: org unit tree not shown correctly in tabular report

Support - Assistance technique
1

I agree in part and definitely prefer to assign access to org units just by selecting the parent rather than multiple units in the same branch. The requirement to select a number of children org units came from the specifications to be able to use the advance search option “all visible” in Find/Add Person. Back in august I started a conversation with Tran to request a way to limit the scope of the search to only the org units a user can access -Thank you Tran!- I’m not familiar with the use case that resulted in the current specification but if you ask me, I’d vote to modify this option to make it work with the selected parent and all the children :slight_smile: -not the same as selected and bellow-. We need this to keep users from searching in all system org units and getting access to person records from different countries or org units out of their allowed scope of work.

Sorry for the detour… back to the bug report. The tabular report is the only section of the system that misbehaves in the way the org unit tree is presented; data entry, visualizer, pivot tables, etc. all present the org unit tree correctly. I’m including two screen captures, one from our development server and another one from the Sierra Leone demo. To duplicate in the demo I created an account and selected National, District and PHU levels.

Best regards,

JM

···

El 04/12/2013, a las 10:35, Lars Helge Øverland larshelge@gmail.com escribió:

Hi Juan, this isn’t exactly a bug, though admittedly a bit confusing.
When selecting an org unit in the tree, the implication is that you
grant access to its sub-tree. You can e.g. select many districts for a
user, which means that the user is granted access to all org units
inside those districts. So there is no need to assign an org unit and
then org units which are part of its sub-tree to a user.

Then I sense that you do this for some reason, like a special
requirement for searching for persons or similar. Lets move this
discussion to the list.

** Changed in: dhis2
Status: New => Invalid

–
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1252954

Title:
org unit tree not shown correctly in tabular report

Status in DHIS 2:
Invalid

Bug description:
In tabular report, for users that have assigned an org unit and several children, the tree is shown with the children and parents in the same level.
To duplicate, create/edit an account with access to tabular report in the demo Sierra Leone, assign the country and select all the children. Login with the account and open the tabular report.

The express selection of an org unit and some or all of the children
is required to use the advanced search option “all visible” in person
management, this also affects the use of the dynamic options in the
selection of the org unit in reports (User org unit / User org unit
children)

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhis2/+bug/1252954/+subscriptions

2

Hi Juan,

okay, I don't quite follow.. What is the difference between "selected
parent and all the children" vs "selected and below" ?

···

On Thu, Dec 5, 2013 at 12:48 AM, Juan M Alcántara Acosta < jmalcantara@apunto.com.mx> wrote:

I agree in part and definitely prefer to assign access to org units just
by selecting the parent rather than multiple units in the same branch. The
requirement to select a number of children org units came from the
specifications to be able to use the advance search option "all visible" in
Find/Add Person. Back in august I started a conversation with Tran to
request a way to limit the scope of the search to only the org units a user
can access -Thank you Tran!- I'm not familiar with the use case that
resulted in the current specification but if you ask me, I'd vote to modify
this option to make it work with the selected parent and all the children
:slight_smile: -not the same as selected and bellow-. We need this to keep users from
searching in all system org units and getting access to person records from
different countries or org units out of their allowed scope of work.

Sorry for the detour... back to the bug report. The tabular report is the
only section of the system that misbehaves in the way the org unit tree is
presented; data entry, visualizer, pivot tables, etc. all present the org
unit tree correctly. I'm including two screen captures, one from our
development server and another one from the Sierra Leone demo. To duplicate
in the demo I created an account and selected National, District and PHU
levels.

3

Hi Lars

I’m sorry I think I did a poor job explaining, the selected parent and all the children I was referring to is the org unit the user is allowed to see/use, so the search would include org unit(s) assigned to the user and all the children.

Let me give you a brief description of what we are doing. We have a first contact program (IPCs) with which we register clients at a municipality level (level 4) and a clinical services program that links services to specific providers (level 6, level 5 is the clinic). When the office receives the report of clinical services they don’t know where the client was first contacted by an IPC and even if they can asume this took place at the same municipality where the clinic is located (not always the case). This is the procedure they use to do this as fast as possible:

  1. Search and select the provider of the clinical service (org unit)

  2. Search for the client by name, it would be great if they could also search by referral number which is a DE in a program.

  3. Once the client is found, the user opens the person panel to enrole the client in the clinical program and add the event(s). At this point the person can be moved to the org unit where the clinical services were received, but they are not doing this to save time.

In this particular case a search on the selected org units (and all bellow) will not return the record of the client since it’s located two levels above and it could even be on a different branch. We have to use “all visible” to get the result and this requires assigning an org unit and some or all of the children.

The users have made two more observations related to the search:

  1. An advance search done with the options “Selected and bellow” and “All visible” takes at least 45 seconds

  2. The search returns all the hits per word. For example, if you search for “Maria Luisa” you’ll get back all the records that contain “Maria” plus all the records that contain “Luisa”. Is there a way to get the results of only the records that contain all the words?

Best regards,

JM

···

On Thu, Dec 5, 2013 at 12:48 AM, Juan M Alcántara Acosta jmalcantara@apunto.com.mx wrote:

I agree in part and definitely prefer to assign access to org units just by selecting the parent rather than multiple units in the same branch. The requirement to select a number of children org units came from the specifications to be able to use the advance search option “all visible” in Find/Add Person. Back in august I started a conversation with Tran to request a way to limit the scope of the search to only the org units a user can access -Thank you Tran!- I’m not familiar with the use case that resulted in the current specification but if you ask me, I’d vote to modify this option to make it work with the selected parent and all the children :slight_smile: -not the same as selected and bellow-. We need this to keep users from searching in all system org units and getting access to person records from different countries or org units out of their allowed scope of work.

Sorry for the detour… back to the bug report. The tabular report is the only section of the system that misbehaves in the way the org unit tree is presented; data entry, visualizer, pivot tables, etc. all present the org unit tree correctly. I’m including two screen captures, one from our development server and another one from the Sierra Leone demo. To duplicate in the demo I created an account and selected National, District and PHU levels.

Hi Juan,

okay, I don’t quite follow… What is the difference between “selected parent and all the children” vs “selected and below” ?

4

Hi Juan,

thanks for explaining this. Its useful to know how you operate.

Hi Lars
I'm sorry I think I did a poor job explaining, the selected parent and all
the children I was referring to is the org unit the user is allowed to
see/use, so the search would include org unit(s) assigned to the user and
all the children.
Let me give you a brief description of what we are doing. We have a first
contact program (IPCs) with which we register clients at a municipality
level (level 4) and a clinical services program that links services to
specific providers (level 6, level 5 is the clinic). When the office
receives the report of clinical services they don't know where the client
was first contacted by an IPC and even if they can asume this took place at
the same municipality where the clinic is located (not always the case).
This is the procedure they use to do this as fast as possible:

1. Search and select the provider of the clinical service (org unit)
2. Search for the client by name, it would be great if they could also
search by referral number which is a DE in a program.

Yes we can do this.

3. Once the client is found, the user opens the person panel to enrole the
client in the clinical program and add the event(s). At this point the
person can be moved to the org unit where the clinical services were
received, but they are not doing this to save time.

In this particular case a search on the selected org units (and all
bellow) will not return the record of the client since it's located two
levels above and it could even be on a different branch. We have to use
"all visible" to get the result and this requires assigning an org unit and
some or all of the children.

Lets just clarify the meaning of all those options:

All: All org units in the system (must require authority)
Children only: Org units in sub-tree(s) from selected org unit(s)
Immediate children: Direct children from the selected org units(s)
Selected: The explicitly selected org units

(I think we need to improve naming here, at least move from "children" to
"sub units".)

So it seems what you would like is to allow users to perform search in a
specific sub-tree of the org unit hierarchy, e.g. to allow search inside a
province or country, but constrain them from searching for other e.g.
countries. And that this permission to search is independent from the
access to registering new clients and registering data, which could be
constrained to another (smaller) sub-tree. Is this correct..?

The users have made two more observations related to the search:
1. An advance search done with the options "Selected and bellow" and "All
visible" takes at least 45 seconds

Yes I know its slow, we hope to rewrite that function for 2.14.

2. The search returns all the hits per word. For example, if you search
for "Maria Luisa" you'll get back all the records that contain "Maria" plus
all the records that contain "Luisa". Is there a way to get the results of
only the records that contain all the words?

Okay I agree, I think that is the way it should be.

regards,

Lars

···

On Tue, Dec 10, 2013 at 6:32 AM, Juan M Alcántara Acosta < jmalcantara@apunto.com.mx> wrote: