dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

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@xxxxxxxxx> 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
> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>