Hi, I wanted to revive this from some time back. The issue of cumulative data is coming up again - any chance for considering adding support for this?
Regards Olav > 7. des. 2015 kl. 13.22 skrev Lars Helge Øverland <[email protected]>: > > Hi Olav, > > On Fri, Dec 4, 2015 at 1:16 PM, Olav Poppe <[email protected] > <mailto:[email protected]>> 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). > > > > 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. > > > 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 > > <https://blueprints.launchpad.net/dhis2/+spec/analysis-apps-fixed-and-user-org-units> > > > 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 > <https://launchpad.net/~dhis2-devs> > Post to : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~dhis2-devs > <https://launchpad.net/~dhis2-devs> > More help : https://help.launchpad.net/ListHelp > <https://help.launchpad.net/ListHelp> > > > > -- > Lars Helge Øverland > Lead developer, DHIS 2 > University of Oslo > Skype: larshelgeoverland > http://www.dhis2.org <https://www.dhis2.org/> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
