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 < [email protected]> 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 <[email protected]>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 <[email protected]> wrote: >> >>> >>> >>> >>> On Fri, Apr 25, 2014 at 10:45 AM, Ola Hodne Titlestad >>> <[email protected]>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 >>> >>> >>> >>> >>> >>> >> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
