Hi, thanks for the reply - comments inline.
> 7. des. 2015 kl. 13.22 skrev Lars Helge Øverland <larshe...@gmail.com>: > > Hi Olav, > >> On Fri, Dec 4, 2015 at 1:16 PM, Olav Poppe <olav.po...@me.com> wrote: >> Hi devs, >> having spent quite a bit of time in recent months defining output and >> dashboards, I’ve come across a few gaps that I’d like to highlight. >> >> The first is an issue I also wrote about on the list some time back, which >> relates to relative periods and "cumulative aggregation" (not sure how to >> phrase it).Programmes that track progress throughout the year (often with >> targets), for example EPI, use "months this year" displayed cumulatively as >> the main way to track progress. By "cumulatively", I mean that the value for >> march (whether it is an indicator or data element) would be jan + feb + >> march, april would be jan + feb + march + april etc. > > okay so what you mean is that data should always be cumulative within the > year? Meaning it is sort of a "so far this year" report? This is a bit more > specific compared to general cumulative function, where one could imagine > having cumulative values across relative periods (e.g. last 12 months). Yes, it’s like a "so far this year" report, but by month (or other type) rather than just the total so far this year. The generic solution might be to add the two things separately: - "months (etc) this year" as relative period, which I think would be useful in it’s own right - a general cumulative function that works across whatever period is selected > > >> >> The second issue is support for some additional relative orgunits, and the >> posibility to combine fixed and relative orgunits (as can be done with >> periods). For relative orgunits, it would be very useful to have "parent >> orgunit", and "peer orgunits" to include orgunits with the same parent as >> the user orgunit. Both allow you to have reusable output that can be used to >> show performance etc relative to related orgunits. > > This becomes a bit of a conflict with the "data view org unit" solution. As > you know, for users we define one or more "data view" org units, which will > define the root of the org unit tree in analysis apps. Often there is a > security aspect to this, in the sense that you do not want to allow people to > see org units outside that boundary/root. So by allowing for peer/parent data > view org units one will violate that principle. Of course we could have Yet > Another Setting for this but that is getting more complicated than most > people appreciate. I suggest that you simply set the data view org unit for > users one level higher up in the hierarchy to achieve this. My thinking in cases where you don’t have access to see peer/parent, or they don’t exist, they would just not be included - similar to the "subunit" orgunit today in cases where the user orgunit doesn't have any subunits. Also, if I’m not mistaken, the relative orgunits use the data entry/maintenance orgunit rather than the data view orgunit, so assigning a user to the "parent" in the data view hierarchy wouldn’t change anything in terms of the relative orgunits. What we want to achieve is that a users in a district can have a favourite/dashboard with his/her district together with the other districts in the same province/region (peers), or that a facility can have a favourite/dashboard with his/her facility vs the overall district data. > > >> That is also the reason I think it would be useful to be able to combine >> fixed and relative orgunits, so that you could for example have a favorite >> showing the indicator for your orgunit with the national value. > > This we can do. In fact combining relative and fixed org units is already > supported in the API so it will be a UI feature. Blueprint: > > https://blueprints.launchpad.net/dhis2/+spec/analysis-apps-fixed-and-user-org-units Great! > > > regards, > > Lars > > > > >> >> Are these things something that could be considered? Would be happy to write >> blueprint(s). >> >> Olav >> >> >> _______________________________________________ >> 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 > > > > -- > Lars Helge Øverland > Lead developer, DHIS 2 > University of Oslo > Skype: larshelgeoverland > http://www.dhis2.org
_______________________________________________ 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
