dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

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@xxxxxxxxxx>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
> 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<https://maps.google.com/maps?q=Eftas%C3%A5sen+68,+0687+Oslo,+Norge&hl=en&ie=UTF8&sll=59.893855,10.785116&sspn=0.222842,0.585709&oq=eftas%C3%A5sen+68,+0687+Oslo,+&t=h&hnear=Eftas%C3%A5sen+68,+%C3%98stensj%C3%B8,+0687+Oslo,+Norway&z=16>
>
>
> On 25 April 2014 11:05, Lars Helge Øverland <larshelge@xxxxxxxxx> wrote:
>
>>
>>
>>
>> On Fri, Apr 25, 2014 at 10:45 AM, Ola Hodne Titlestad <olati@xxxxxxxxxx>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
>>
>>
>>
>>
>>
>>
>