dhis2-devs team mailing list archive

[Olav Poppe <olav.poppe@xxxxxx>]

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 <larshelge@xxxxxxxxx>:
> 
> Hi Olav,
> 
> On Fri, Dec 4, 2015 at 1:16 PM, Olav Poppe <olav.poppe@xxxxxx <mailto:olav.poppe@xxxxxx>> 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     : dhis2-devs@xxxxxxxxxxxxxxxxxxx <mailto:dhis2-devs@xxxxxxxxxxxxxxxxxxx>
> 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/>
>