User orgunit graphs in 2.15

Dear Devs,
We are trying to figure out how to best use the new functionality which splits the analysis and maintenance orgunits. In our case, the district health officers should be allowed to maintain their own facilities, but should also be allowed to view data from other districts (and provinces). When we create graphs using “User orgunit”, the graphs appear at the national level, when the district officers are assigned to the national level as their analysis orgunit. When we assign the district level user to their own district as their analysis unit, they are no longer able to view data from other district. I know the reason of why this has been done, but for some implementations, the systems needs to be more open, so that users can view data from their own districts as well as their own, similar to how it was in previous versions.

How do you suggest that we handle this situation?

Regards,

Jason

Hi Jason,

like you point out we switched to using the “data view org unit” as basis for the “user org unit” in analysis.

I guess your problem is that you would like the user org unit to work like before, in your case display the district, while still allow users to access and view data for the country.

I suspect that some would like it the way it is in 2.15, but I am open to going back to use the “data capture” org unit as basis for “user org unit”. Anyone with strong opinions in this matter?

regards,

Lars

···

On Fri, Apr 25, 2014 at 6:10 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Dear Devs,
We are trying to figure out how to best use the new functionality which splits the analysis and maintenance orgunits. In our case, the district health officers should be allowed to maintain their own facilities, but should also be allowed to view data from other districts (and provinces). When we create graphs using “User orgunit”, the graphs appear at the national level, when the district officers are assigned to the national level as their analysis orgunit. When we assign the district level user to their own district as their analysis unit, they are no longer able to view data from other district. I know the reason of why this has been done, but for some implementations, the systems needs to be more open, so that users can view data from their own districts as well as their own, similar to how it was in previous versions.

How do you suggest that we handle this situation?

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

I think it makes much more sense for the “User Orgunit parameter” to be the actual orgunit of the user (what I guess is now called data capture orgunit), so that the data most important/relevant to the user is what is shown on the dashboard etc.

What data the user can access beyond/above that in the hierarchy is a separate issue.

Given that we try to make the default behaviour in 2.15 “just as before”, but with the option to use these new control features where appropriate, I think the user orgunit should also be “just as before”.

Ola

···

Ola Hodne Titlestad (Mr)
HISP
Department of Informatics

University of Oslo

Mobile: +47 48069736
Home address: Eftasåsen 68, 0687 Oslo, Norway. Googlemaps link

On 25 April 2014 10:33, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Jason,

like you point out we switched to using the “data view org unit” as basis for the “user org unit” in analysis.

I guess your problem is that you would like the user org unit to work like before, in your case display the district, while still allow users to access and view data for the country.

I suspect that some would like it the way it is in 2.15, but I am open to going back to use the “data capture” org unit as basis for “user org unit”. Anyone with strong opinions in this matter?

regards,

Lars


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Fri, Apr 25, 2014 at 6:10 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Dear Devs,
We are trying to figure out how to best use the new functionality which splits the analysis and maintenance orgunits. In our case, the district health officers should be allowed to maintain their own facilities, but should also be allowed to view data from other districts (and provinces). When we create graphs using “User orgunit”, the graphs appear at the national level, when the district officers are assigned to the national level as their analysis orgunit. When we assign the district level user to their own district as their analysis unit, they are no longer able to view data from other district. I know the reason of why this has been done, but for some implementations, the systems needs to be more open, so that users can view data from their own districts as well as their own, similar to how it was in previous versions.

How do you suggest that we handle this situation?

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

The user org unit will first try to use data view org unit, if none is not
defined it will fall back to the data capture org unit, so there will be no
change for current systems.

That said we can change to use data capture org unit. Then one might argue
that the org unit used for viewing data should be the data view org unit.
Of course we could make that configurable with a setting, with the cost of
making things more complex.

Lars

···

On Fri, Apr 25, 2014 at 10:45 AM, Ola Hodne Titlestad <olati@ifi.uio.no>wrote:

I think it makes much more sense for the "User Orgunit parameter" to be
the actual orgunit of the user (what I guess is now called data capture
orgunit), so that the data most important/relevant to the user is what is
shown on the dashboard etc.

What data the user can access beyond/above that in the hierarchy is a
separate issue.

Given that we try to make the default behaviour in 2.15 "just as before",
but with the option to use these new control features where appropriate, I
think the user orgunit should also be "just as before".

In a way we have three different concepts concerning orgunit+user here:

  1. the home orgunit - where the user work - says something about the priority geographical area / facility of the user

  2. the orgunit tree for data entry/input - what the user has access to in data entry

  3. the orgunit tree for reports/outputs - what the user has access to in reports/analysis modules

My usage of the “user orgunit parameter” for analysis outputs so far has been related to 1) above, as the point has been to present the most relevant data to the user that is logged in, either about the user’s “hone orgunit” or its “children”. Typically the data entry unit will be closer match to that than the data view orgunit, but it all depends on the local policies for data sharing, so hard to assume anything here.

So I am not sure it works to combine these three concepts into two, which we are doing at the moment. So my suggestion would be to have three user/orgunit options, one for each of the above.

Ola

···

Ola Hodne Titlestad (Mr)
HISP
Department of Informatics

University of Oslo

Mobile: +47 48069736
Home address: Eftasåsen 68, 0687 Oslo, Norway. Googlemaps link

On 25 April 2014 11:05, Lars Helge Øverland larshelge@gmail.com wrote:

On Fri, Apr 25, 2014 at 10:45 AM, Ola Hodne Titlestad olati@ifi.uio.no wrote:

I think it makes much more sense for the “User Orgunit parameter” to be the actual orgunit of the user (what I guess is now called data capture orgunit), so that the data most important/relevant to the user is what is shown on the dashboard etc.

What data the user can access beyond/above that in the hierarchy is a separate issue.

Given that we try to make the default behaviour in 2.15 “just as before”, but with the option to use these new control features where appropriate, I think the user orgunit should also be “just as before”.

The user org unit will first try to use data view org unit, if none is not defined it will fall back to the data capture org unit, so there will be no change for current systems.

That said we can change to use data capture org unit. Then one might argue that the org unit used for viewing data should be the data view org unit. Of course we could make that configurable with a setting, with the cost of making things more complex.

Lars

Hi Lars and Ola,

Maybe it is simply my lack of understanding of exactly how this works in our case (RTFM perhaps?).

So, if the data view org unit is not set,

  1. The “user orgunit” will be the data capture unit

  2. The user will still have access to the entire hierarchy.

If the data view orgunit is set, it will override the data capture unit.

If it works this way, then I am fine with it and we can work with this.

Best regards,
Jason

···

On Fri, Apr 25, 2014 at 4:15 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:

In a way we have three different concepts concerning orgunit+user here:

  1. the home orgunit - where the user work - says something about the priority geographical area / facility of the user
  1. the orgunit tree for data entry/input - what the user has access to in data entry
  1. the orgunit tree for reports/outputs - what the user has access to in reports/analysis modules

My usage of the “user orgunit parameter” for analysis outputs so far has been related to 1) above, as the point has been to present the most relevant data to the user that is logged in, either about the user’s “hone orgunit” or its “children”. Typically the data entry unit will be closer match to that than the data view orgunit, but it all depends on the local policies for data sharing, so hard to assume anything here.

So I am not sure it works to combine these three concepts into two, which we are doing at the moment. So my suggestion would be to have three user/orgunit options, one for each of the above.

Ola



Ola Hodne Titlestad (Mr)

HISP
Department of Informatics

University of Oslo

Mobile: +47 48069736
Home address: Eftasåsen 68, 0687 Oslo, Norway. Googlemaps link

On 25 April 2014 11:05, Lars Helge Øverland larshelge@gmail.com wrote:

On Fri, Apr 25, 2014 at 10:45 AM, Ola Hodne Titlestad olati@ifi.uio.no wrote:

I think it makes much more sense for the “User Orgunit parameter” to be the actual orgunit of the user (what I guess is now called data capture orgunit), so that the data most important/relevant to the user is what is shown on the dashboard etc.

What data the user can access beyond/above that in the hierarchy is a separate issue.

Given that we try to make the default behaviour in 2.15 “just as before”, but with the option to use these new control features where appropriate, I think the user orgunit should also be “just as before”.

The user org unit will first try to use data view org unit, if none is not defined it will fall back to the data capture org unit, so there will be no change for current systems.

That said we can change to use data capture org unit. Then one might argue that the org unit used for viewing data should be the data view org unit. Of course we could make that configurable with a setting, with the cost of making things more complex.

Lars

Yes that is correct. Data view org unit can be completely ignored which means no change in current behavior.

Lars

···

On Fri, Apr 25, 2014 at 2:59 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Lars and Ola,

Maybe it is simply my lack of understanding of exactly how this works in our case (RTFM perhaps?).

So, if the data view org unit is not set,

  1. The “user orgunit” will be the data capture unit
  1. The user will still have access to the entire hierarchy.

If the data view orgunit is set, it will override the data capture unit.

If it works this way, then I am fine with it and we can work with this.

Best regards,
Jason

On Fri, Apr 25, 2014 at 4:15 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:

In a way we have three different concepts concerning orgunit+user here:

  1. the home orgunit - where the user work - says something about the priority geographical area / facility of the user
  1. the orgunit tree for data entry/input - what the user has access to in data entry
  1. the orgunit tree for reports/outputs - what the user has access to in reports/analysis modules

My usage of the “user orgunit parameter” for analysis outputs so far has been related to 1) above, as the point has been to present the most relevant data to the user that is logged in, either about the user’s “hone orgunit” or its “children”. Typically the data entry unit will be closer match to that than the data view orgunit, but it all depends on the local policies for data sharing, so hard to assume anything here.

So I am not sure it works to combine these three concepts into two, which we are doing at the moment. So my suggestion would be to have three user/orgunit options, one for each of the above.

Ola



Ola Hodne Titlestad (Mr)

HISP
Department of Informatics

University of Oslo

Mobile: +47 48069736
Home address: Eftasåsen 68, 0687 Oslo, Norway. Googlemaps link

On 25 April 2014 11:05, Lars Helge Øverland larshelge@gmail.com wrote:

On Fri, Apr 25, 2014 at 10:45 AM, Ola Hodne Titlestad olati@ifi.uio.no wrote:

I think it makes much more sense for the “User Orgunit parameter” to be the actual orgunit of the user (what I guess is now called data capture orgunit), so that the data most important/relevant to the user is what is shown on the dashboard etc.

What data the user can access beyond/above that in the hierarchy is a separate issue.

Given that we try to make the default behaviour in 2.15 “just as before”, but with the option to use these new control features where appropriate, I think the user orgunit should also be “just as before”.

The user org unit will first try to use data view org unit, if none is not defined it will fall back to the data capture org unit, so there will be no change for current systems.

That said we can change to use data capture org unit. Then one might argue that the org unit used for viewing data should be the data view org unit. Of course we could make that configurable with a setting, with the cost of making things more complex.

Lars

I have updated TFM now.