To all of you maintaining in-production DHIS 2 systems, especially those with many installations, we highly recommend to wait with updating the application until we have released a final 2.0.5 version. It should not be many days away. For non-production installations, the almost release-ready code in the 2.0.5 branch referred to below is the recommended one, and should be fairly stable by now. It is a good idea to start using it now, if you haven’t already, to get familiar with the new features and to solve any possible update issues with your databases, so that you are better prepared when the 2.0.5 version is out. If you come across any bugs with this code your bug reports are of course highly welcome and important for us in stabilising this new version.
Thanks.
···
---------- Forwarded message ----------
From: Ola Hodne Titlestadolati@ifi.uio.no
Date: 2010/10/20
Just a quick update.
Knut made we aware of the hudson build for 2.0.5, so if you just want a pre-built war file of the latest 2.0.5 you can download the file here:
(including the list as this is probably relevant to many of you)
Aymar, please upgrade to the latest revision of the 2.0.5 branch which is now almost ready for release.
There have been some major changes and improvements to data set sections during the last month in the 2.0.5 code and we are aware that there were some problems with sections in earlier 2.0.5 revisions.
Since 2.0.5 is a release branch it is getting more and more stable every day up to release date, so always a good reason to update to the latest if you are already using 2.0.5.
The latest code in the trunk branch, which is 2.0.6-SNAPSHOT is much more experimental and unstable and is not recommended to use for more than testing purposes right now. That branch will still undergo many changes before the 2.0.6 release, which will probably be at least 2 months from now.
There is no automatically built .war file available for 2.0.5 on the hudson server, so you will need to download the source code and build the war file locally.
If that is problematic I can make a .war file (of 2.0.5 revision 2068) available for download. Let me know.
To get a local copy of the 2.0.5 release branch you need bazaar installed and then the following command:
$bzr branch lp:~dhis2-devs-core/dhis2/2.0.5
(more info on http://dhis2.org/development , but note the different branch url above that you need to use to get the 2.0.5 branch)
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo
Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link
In our Ghana implementation, for some childbirth information, teaching hospitals use one form (Form A) and other facilities use another (Form B). For some data which the two forms gather in common, Form A is more disaggregated (A1[x,y]) than Form B (B1[x]). The data for A1 appears as a grid with totals for A1[x,*], A1[*,y], A1[*,*], which are calculated variables that appear on the form and the dataset report. Similarly, the data for B1 appears as a list with a total for B1[*]. A1 and B1 are to be aggregated for all statistics and indicators. Am I correct that I need to use either another calculated variable (Q1 = A1+B1) or the expression A1+B1 in all my statistics and indicators? If I want to coerce Form A data into a Form B dataset report at the aggregate level, I have to create a new dataset with all calculated variables of the form A1[x,*]+B1[x]? Am I better off adding an N/A value for y and collecting A1[x,N/A] on Form B?
I think what you suggest is right, although Ola is probably the
authoritative source for the answer. A calculated data element would
seem to be the correct way to go.
I would strongly discourage the second alternative, as it is entirely
possible that people would enter something anyway other than N/A in
Form B. ( I have seen this happen here)
Regards,
Jason
···
On Fri, Nov 5, 2010 at 2:42 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <rdf4@cdc.gov> wrote:
Folks –
In our Ghana implementation, for some childbirth information, teaching
hospitals use one form (Form A) and other facilities use another (Form B).
For some data which the two forms gather in common, Form A is more
disaggregated (A1[x,y]) than Form B (B1). The data for A1 appears as a
grid with totals for A1[x,*], A1[*,y], A1[*,*], which are calculated
variables that appear on the form and the dataset report. Similarly, the
data for B1 appears as a list with a total for B1[*]. A1 and B1 are to be
aggregated for all statistics and indicators. Am I correct that I need to
use either another calculated variable (Q1 = A1+B1) or the expression A1+B1
in all my statistics and indicators? If I want to coerce Form A data into a
Form B dataset report at the aggregate level, I have to create a new dataset
with all calculated variables of the form A1[x,*]+B1? Am I better off
adding an N/A value for y and collecting A1[x,N/A] on Form B?
The best approach, although not always possible, would be to make sure the two forms use the same disaggregations (catcombo), to reuse data elements across the data sets.
For some of these calculated elements it might make more sense to use indicators in stead of calculated data elements as the indicator expressions are more flexible.
Viewing calculated data element values in data entry does not work anyway, and as I mentioned yesterday we are likely to move towards a more robust expression model for use in custom data entry forms, meaning that any expression (incl. indicators) can be inserted into a custom form and represent totals and other calculations (e.g stock end balances).
And in stead of doing data set reports and use such a combined data set for reports only, I would design reports using iReport/jasper or BIRT and bring in data elements, calculated or raw, and indicators together there, which will give you more flexibility.
···
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo
Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link