Re: [Dhis2-devs] [Dhis2-users] dhis to submit anonymous data
Hi Lars and Jason, Good idea, and good questions about security. One way to approach IP address security is to not record them anywhere (and make sure the central server to which the data is sent does not keep any log of them.) If the central server doesn't know the IP addresses, they can't be divulged to any third party. A very different approach to openness and security is taken by the optional OpenMRS "Atlas module". This opt-in module allows an OpenMRS installation to provide information that is available in a public OpenMRS "atlas" of implementations. The atlas can facilitate interactions between OpenMRS community members, including prospective members, and it also serves as publicity for OpenMRS as well as the implementers. I'll leave it for others to say whether DHIS2 administrators would feel comfortable or even welcome this kind of public information for their implementations. See http://openmrs.org/atlas/ for the OpenMRS atlas itself, and https://wiki.openmrs.org/display/docs/Atlas+Module+User+Guide for the atlas module user guide. Cheers, Jim On Jun 28, 2013, at 9:22 AM, Jason Pickering wrote: > Hi Lars, > > Sounds interesting. Wish I would have been there for the discussion. Sounds > like it might be possible, assuming the process and data is transparent, and > allow for an option to "opt-out" of collection of such data. > > Having said that, I think we should be exceedingly careful. I assume that the > data would be beamed back to a central server someplace. Who would control > that server? Who would have access to the "sensitive" data like IP addresses > of the servers, i.e. the data which would not be publicly disclosed? Given > recent revelations in the news, how would possible data requests from third > parties be handled (such as a list of IP addresses for where DHIS2 is used)? > > Regards, > Jason > > > > > > On Thu, Jun 27, 2013 at 10:07 PM, Lars Helge Øverland > wrote: > Hi there, > > during the Uganda workshop last month we had an interesting suggestion from > one of the participants. > > The idea is to let DHIS submit anonymous, non-sensitive data to a central > system in order to gather basic statistics related to usage. The data sent > would include: > > - A random, anonymous system identifier > - DHIS 2 version > - Java server version > - Operating system and version > > Then we could make an optional feature for "activating" or "registering" your > DHIS instance, where you could optionally inform about: > > - System contact person > - System description > > It would be quite useful and interesting to know things like: > > - How many DHIS instances there are out there > - How fast are new DHIS versions adopted > - What is the dominant server operating system/environment > > > This info would of course be disclosed only in aggregate form. > > What do people think about this? Any strong objections? > > > best regards, > > Lars > > > ___ > Mailing list: https://launchpad.net/~dhis2-users > Post to : dhis2-us...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-users > More help : https://help.launchpad.net/ListHelp > > > ___ > Mailing list: https://launchpad.net/~dhis2-users > Post to : dhis2-us...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-users > More help : https://help.launchpad.net/ListHelp ___ 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
[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 11275: (PT) dx/dc/co issue fixed.
Merge authors:
Jan Henrik Øverland (janhenrik-overland)
revno: 11275 [merge]
committer: Jan Henrik Overland
branch nick: dhis2
timestamp: Fri 2013-06-28 12:43:28 +0200
message:
(PT) dx/dc/co issue fixed.
modified:
dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js
dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/core.js
--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk
Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription
=== modified file 'dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js'
--- dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js 2013-06-27 16:41:44 +
+++ dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js 2013-06-28 10:42:07 +
@@ -3846,6 +3846,12 @@
return;
}
+// dc and co
+if (objectNameDimensionMap[dimConf.operand.objectName] && objectNameDimensionMap[dimConf.category.objectName]) {
+ alert('Categories and detailed data elements cannot be specified together');
+ return;
+}
+
// Degs and datasets in the same query
//if (Ext.Array.contains(dimensionNames, dimConf.data.dimensionName) && pt.store.dataSetSelected.data.length) {
//for (var i = 0; i < pt.init.degs.length; i++) {
=== modified file 'dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/core.js'
--- dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/core.js 2013-06-26 16:11:35 +
+++ dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/core.js 2013-06-28 10:42:07 +
@@ -738,7 +738,8 @@
dimConf = pt.conf.finals.dimension,
addCategoryDimension = false,
map = xLayout.dimensionNameItemsMap,
-dx = dimConf.indicator.dimensionName;
+dx = dimConf.indicator.dimensionName,
+co = dimConf.category.dimensionName;
for (var i = 0, dimName, items; i < axisDimensionNames.length; i++) {
dimName = axisDimensionNames[i];
@@ -759,8 +760,8 @@
items = Ext.Array.unique(items);
}
-
-if (dimName !== dimConf.category.dimensionName) {
+
+if (dimName !== co) {
paramString += ':' + items.join(';');
}
@@ -768,7 +769,7 @@
paramString += '&';
}
}
-
+
if (addCategoryDimension) {
paramString += '&dimension=' + pt.conf.finals.dimension.category.dimensionName;
}
@@ -970,6 +971,8 @@
var createValueIdMap = function() {
var valueHeaderIndex = response.nameHeaderMap[pt.conf.finals.dimension.value.value].index,
coHeader = response.nameHeaderMap[pt.conf.finals.dimension.category.dimensionName],
+ dx = dimConf.data.dimensionName,
+ co = dimConf.category.dimensionName,
axisDimensionNames = xLayout.axisDimensionNames,
idIndexOrder = [];
@@ -977,8 +980,8 @@
for (var i = 0; i < axisDimensionNames.length; i++) {
idIndexOrder.push(response.nameHeaderMap[axisDimensionNames[i]].index);
- // If co exists in response, add co after dx
- if (coHeader && axisDimensionNames[i] === pt.conf.finals.dimension.data.dimensionName) {
+ // If co exists in response and is not added in layout, add co after dx
+ if (coHeader && !Ext.Array.contains(axisDimensionNames, co) && axisDimensionNames[i] === dx) {
idIndexOrder.push(coHeader.index);
}
}
@@ -1462,17 +1465,17 @@
}
// Value objects
- for (var i = 0, valueItemsRow, valueObjectsRow, map = Ext.clone(xResponse.idValueMap); i < rowSize; i++) {
+ for (var i = 0, valueItemsRow, valueObjectsRow, idValueMap = Ext.clone(xResponse.idValueMap); i < rowSize; i++) {
valueItemsRow = [];
valueObjectsRow = [];
for (var j = 0, id, value, htmlValue, empty; j < colSize; j++) {
id = (xColAxis ? pt.util.str.replaceAll(xColAxis.ids[j], '-', '') : '') + (xRowAxis ? pt.util.str.replaceAll(xRowAxis.ids[i], '-', '') : '');
empty = false;
-
- if (map[id]) {
-value = parseFloat(map[id]);
-htmlValue = pt.util.number.roundIf(map[id], 1).toString();
+console.log(id);
+ if (idValueMap[id]) {
+value = parseFloat(idValueMap[id]);
+htmlValue = pt.util.number.roundIf(idValueMap[id], 1).toString();
}
else {
value = 0;
@@ -1963,9 +1966,8 @@
alert(r.responseText);
},
success: function(r) {
- var layoutConfig = Ext.decode(r.responseText);
-
- var layout = pt.api.layout.Layout(layoutConfig);
+ var layoutConfig = Ext.decode(r.responseText),
+ layout = pt.api.layout.Layout(layoutConfig);
if (layout) {
pt.favorite = Ext.clone(layout);
___
Mailing list: https://launchpad.net/~
[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 11276: (DV) Chart and api links added to interpretation window.
Merge authors:
Jan Henrik Øverland (janhenrik-overland)
revno: 11276 [merge]
committer: Jan Henrik Overland
branch nick: dhis2
timestamp: Fri 2013-06-28 13:53:56 +0200
message:
(DV) Chart and api links added to interpretation window.
modified:
dhis-2/dhis-web/dhis-web-visualizer/src/main/webapp/dhis-web-visualizer/app/scripts/app.js
--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk
Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription
=== modified file 'dhis-2/dhis-web/dhis-web-visualizer/src/main/webapp/dhis-web-visualizer/app/scripts/app.js'
--- dhis-2/dhis-web/dhis-web-visualizer/src/main/webapp/dhis-web-visualizer/app/scripts/app.js 2013-06-26 16:11:35 +
+++ dhis-2/dhis-web/dhis-web-visualizer/src/main/webapp/dhis-web-visualizer/app/scripts/app.js 2013-06-28 11:52:44 +
@@ -1900,8 +1900,16 @@
});
linkPanel = Ext.create('Ext.panel.Panel', {
-html: 'Link: ' + dv.baseUrl + '/dhis-web-visualizer/app/index.html?id=' + dv.favorite.id + '',
-style: 'padding-top: 9px; padding-bottom: 6px',
+html: function() {
+ var chartUrl = dv.baseUrl + '/dhis-web-visualizer/app/index.html?id=' + dv.favorite.id,
+ apiUrl = dv.baseUrl + '/api/charts/' + dv.favorite.id + '/data',
+ html = '';
+
+ html += 'Chart link: ' + chartUrl + '';
+ html += 'API link: ' + apiUrl + '';
+ return html;
+}(),
+style: 'padding-top: 8px; padding-bottom: 5px',
bodyStyle: 'border: 0 none'
});
___
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
[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 11277: (PT) Pivot table and api links added to interpretation window.
Merge authors:
Jan Henrik Øverland (janhenrik-overland)
revno: 11277 [merge]
committer: Jan Henrik Overland
branch nick: dhis2
timestamp: Fri 2013-06-28 14:10:53 +0200
message:
(PT) Pivot table and api links added to interpretation window.
modified:
dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js
--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk
Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription
=== modified file 'dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js'
--- dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js 2013-06-28 10:42:07 +
+++ dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js 2013-06-28 12:06:57 +
@@ -2012,8 +2012,16 @@
});
linkPanel = Ext.create('Ext.panel.Panel', {
-html: 'Link: ' + pt.baseUrl + '/dhis-web-pivot/app/index.html?id=' + pt.favorite.id + '',
-style: 'padding-top: 9px; padding-bottom: 6px',
+html: function() {
+ var reportTableUrl = pt.baseUrl + '/dhis-web-pivot/app/index.html?id=' + pt.favorite.id,
+ apiUrl = pt.baseUrl + '/api/reportTables/' + pt.favorite.id + '/data.html',
+ html = '';
+
+ html += 'Chart link: ' + reportTableUrl + '';
+ html += 'API link: ' + apiUrl + '';
+ return html;
+}(),
+style: 'padding-top: 8px; padding-bottom: 5px',
bodyStyle: 'border: 0 none'
});
___
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
[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 11278: Minor fix.
Merge authors: Jan Henrik Øverland (janhenrik-overland) revno: 11278 [merge] committer: Jan Henrik Overland branch nick: dhis2 timestamp: Fri 2013-06-28 14:12:09 +0200 message: Minor fix. modified: dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js -- lp:dhis2 https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk Your team DHIS 2 developers is subscribed to branch lp:dhis2. To unsubscribe from this branch go to https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription === modified file 'dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js' --- dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js 2013-06-28 12:06:57 + +++ dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js 2013-06-28 12:11:39 + @@ -2017,7 +2017,7 @@ apiUrl = pt.baseUrl + '/api/reportTables/' + pt.favorite.id + '/data.html', html = ''; - html += 'Chart link: ' + reportTableUrl + ''; + html += 'Pivot link: ' + reportTableUrl + ''; html += 'API link: ' + apiUrl + ''; return html; }(), ___ 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
[Dhis2-devs] [Bug 1192604] Re: Option set UI not working well with very large option sets
** Changed in: dhis2 Assignee: (unassigned) => Morten Olav Hansen (mortenoh) -- You received this bug notification because you are a member of DHIS 2 developers, which is subscribed to DHIS. https://bugs.launchpad.net/bugs/1192604 Title: Option set UI not working well with very large option sets Status in DHIS 2 - District Health Information Software: New Bug description: The option set user interface is not working well for very large option sets. For instance for icd 10 options, which can be up to 14 000 options, when trying to save the option set, the request might time out or be too large for the webserver to accept, leading to the option set to drop all options. We need to make a user interface which does not require all options to be sent to the server. To manage notifications about this bug go to: https://bugs.launchpad.net/dhis2/+bug/1192604/+subscriptions ___ 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
Re: [Dhis2-devs] [Dhis2-users] dhis to submit anonymous data
Hi, thanks for the good questions and comments. This information will be stored in some central system. The system will be managed by the DHIS core team. That system will be made open source so that anyone who feels like it could investigate it. > Who would have access to the "sensitive" data like IP addresses of the > servers, i.e. the data which would not be publicly disclosed? Given recent > revelations in the news, how would possible data requests from third > parties be handled (such as a list of IP addresses for where DHIS2 is used)? > > We will simply not store IP addresses. We are not interested in them anyway, and to avoid any thinkable doubt of misuse or NSA inquiries we will not store them. I am thinking that for this function to have a purpose, it should not be possible to opt out of the very basic, anonymous data, like DHIS version and random system identifier. If optional then the statistics wouldn't be very useful. If that is not acceptable we would rather drop the feature. Of course, the "activation" feature with contact person etc would be completely optional and require that you actively enable it. One way to approach IP address security is to not record them anywhere (and > make sure the central server to which the data is sent does not keep any > log of them.) If the central server doesn't know the IP addresses, they > can't be divulged to any third party. > > Agreed. > A very different approach to openness and security is taken by the > optional OpenMRS "Atlas module". This opt-in module allows an OpenMRS > installation to provide information that is available in a public OpenMRS > "atlas" of implementations. The atlas can facilitate interactions between > OpenMRS community members, including prospective members, and it also > serves as publicity for OpenMRS as well as the implementers. I'll leave it > for others to say whether DHIS2 administrators would feel comfortable or > even welcome this kind of public information for their implementations. See > http://openmrs.org/atlas/ for the OpenMRS atlas itself, and > https://wiki.openmrs.org/display/docs/Atlas+Module+User+Guide for the > atlas module user guide. > Thanks for the tip, I will check out the atlas module for inspiration. Another idea for this concept: The DHIS instances could be checking with a central system whether new major versions of DHIS are available for download or whether any critical bugfixes are available for the current major version. This notifications could be made available through the DHIS messaging system and be sent to some group of system admin users. More comments are welcome. cheers Lars ___ 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
[Dhis2-devs] [Bug 1170104] Re: SQL View: Downloads only include rows from the current page
I was thinking about cases in which the resulting view is extremely large, but I agree it makes sense to have just one option to download all the data. The way I've worked around this limitation is setting the number of rows per page to allow all the records to be displayed in a single page, this works well with views that return a moderate number of records. -- You received this bug notification because you are a member of DHIS 2 developers, which is subscribed to DHIS. https://bugs.launchpad.net/bugs/1170104 Title: SQL View: Downloads only include rows from the current page Status in DHIS 2 - District Health Information Software: New Bug description: When downloading an sql view to Excel or CSV only the rows included on the current page are downloaded (if the result set is paged over multiple pages). This is very confusing. We should get all values/rows in the result set into the downloaded file. To manage notifications about this bug go to: https://bugs.launchpad.net/dhis2/+bug/1170104/+subscriptions ___ 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
[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 11279: (PT, DV) Detailed data element gui issues fixed.
Merge authors:
Jan Henrik Øverland (janhenrik-overland)
revno: 11279 [merge]
committer: Jan Henrik Overland
branch nick: dhis2
timestamp: Fri 2013-06-28 15:16:49 +0200
message:
(PT, DV) Detailed data element gui issues fixed.
modified:
dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js
dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/core.js
dhis-2/dhis-web/dhis-web-visualizer/src/main/webapp/dhis-web-visualizer/app/scripts/app.js
--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk
Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription
=== modified file 'dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js'
--- dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js 2013-06-28 12:11:39 +
+++ dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/app.js 2013-06-28 13:15:50 +
@@ -332,11 +332,12 @@
this.load({
scope: this,
callback: function() {
- this.sortStore();
+ pt.util.multiselect.filterAvailable({store: this}, {store: store.dataElementSelected});
}
});
},
setDetailsProxy: function(uid) {
+console.log(uid);
if (Ext.isString(uid)) {
this.setProxy({
type: 'ajax',
@@ -354,8 +355,8 @@
r.set('id', r.data.dataElementId + '-' + r.data.optionComboId);
r.set('name', r.data.operandName);
});
-
- this.sortStore();
+
+ pt.util.multiselect.filterAvailable({store: this}, {store: store.dataElementSelected});
}
});
}
@@ -4249,6 +4250,14 @@
pt.util.multiselect.filterAvailable({store: pt.store.dataElementAvailable}, {store: pt.store.dataElementSelected});
}
+// Operands
+objectName = dimConf.operand.objectName;
+if (dimMap[objectName]) {
+ pt.store.dataElementSelected.add(Ext.clone(recMap[objectName]));
+ pt.util.multiselect.filterAvailable({store: pt.store.dataElementAvailable}, {store: pt.store.dataElementSelected});
+ dataElementDetailLevel.setValue(objectName);
+}
+
// Data sets
pt.store.dataSetSelected.removeAll();
objectName = dimConf.dataSet.objectName;
@@ -4419,6 +4428,7 @@
interpretationButton: interpretationButton,
userOrganisationUnit: userOrganisationUnit,
userOrganisationUnitChildren: userOrganisationUnitChildren,
+dataElementDetailLevel: dataElementDetailLevel,
setFavorite: setFavorite,
items: [
westRegion,
=== modified file 'dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/core.js'
--- dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/core.js 2013-06-28 10:42:07 +
+++ dhis-2/dhis-web/dhis-web-pivot/src/main/webapp/dhis-web-pivot/app/scripts/core.js 2013-06-28 13:15:50 +
@@ -1472,7 +1472,7 @@
for (var j = 0, id, value, htmlValue, empty; j < colSize; j++) {
id = (xColAxis ? pt.util.str.replaceAll(xColAxis.ids[j], '-', '') : '') + (xRowAxis ? pt.util.str.replaceAll(xRowAxis.ids[i], '-', '') : '');
empty = false;
-console.log(id);
+
if (idValueMap[id]) {
value = parseFloat(idValueMap[id]);
htmlValue = pt.util.number.roundIf(idValueMap[id], 1).toString();
=== modified file 'dhis-2/dhis-web/dhis-web-visualizer/src/main/webapp/dhis-web-visualizer/app/scripts/app.js'
--- dhis-2/dhis-web/dhis-web-visualizer/src/main/webapp/dhis-web-visualizer/app/scripts/app.js 2013-06-28 11:52:44 +
+++ dhis-2/dhis-web/dhis-web-visualizer/src/main/webapp/dhis-web-visualizer/app/scripts/app.js 2013-06-28 13:15:50 +
@@ -284,7 +284,7 @@
a.store.clearFilter();
this.filterAvailable(a, s);
},
- filterAvailable: function(a, s) {
+ filterAvailable: function(a, s) {
a.store.filterBy( function(r) {
var keep = true;
s.store.each( function(r2) {
@@ -598,7 +598,7 @@
this.load({
scope: this,
callback: function() {
- this.sortStore();
+ dv.util.multiselect.filterAvailable({store: this}, {store: store.dataElementSelected});
}
});
},
@@ -620,14 +620,19 @@
r.set('id', r.data.dataElementId + '-' + r.data.optionComboId);
r.set('name', r.data.operandName);
});
-
- this.sortStore();
+
+ dv.util.multiselect.filterAvailable({store: this}, {store: store.dataElementSelected});
}
});
}
else {
alert('Invalid parameter');
}
+ },
+ listeners: {
+load: function(s) {
+
+}
}
});
@@ -4378,6 +4383,7 @@
dv.util.chart.createChart(layout, dv);
// Set gui
+
xLayout = dv.util.chart.getExtendedLayout(layout);
dimMap = xLayout.objectNameDimensionsMap;
recMap = xLayout.obj
Re: [Dhis2-devs] [Dhis2-users] Translations to French and Spanish
Hello Bob Thank you for the link. I posted to the group a couple of days ago but I see there's not much movement there, there are 15 messages sense Dec. 2012 (including mine) JM El 26/06/2013, a las 06:00, Bob Jolliffe escribió: > Hi Juan > > I think a lot of the Spanish activities around dhis2, including considerable > translation work, have been co-ordinated through people who are members of a > google group https://groups.google.com/forum/?hl=en#!forum/dhis2-usuarios so > might also make sense to get in touch with them. > > Bob > > > On 26 June 2013 11:31, Lars Helge Øverland wrote: > Hi Juan, > > yes we have an active community of translators. I am aware that labels for > some of the new features in 2.12 is not yet translated. Hopefully we will be > able to fix that soon. > > From your name it seems you know a word or two of Spanish; if you feel like > contributing to the docs, the process is well documented here: > > http://www.dhis2.org/doc/snapshot/en/implementer/dhis2_documentation_guide.pdf > > Otherwise, Jason Pickering is overseeing the documentation effort and he > might be able to assist you if you get stuck. > > best regards, > > Lars > > > > > > > On Tue, Jun 25, 2013 at 10:12 PM, Juan M Alcántara Acosta > wrote: > Hello everyone > Is someone currently working on the translation of the interface to Spanish > and French? > Best regards, > JM > ___ > Mailing list: https://launchpad.net/~dhis2-users > Post to : dhis2-us...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-users > More help : https://help.launchpad.net/ListHelp > > > ___ > Mailing list: https://launchpad.net/~dhis2-users > Post to : dhis2-us...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-users > More help : https://help.launchpad.net/ListHelp > > ___ 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
Re: [Dhis2-devs] [Bug 1170104] Re: SQL View: Downloads only include rows from the current page
Okay thanks. Yes I think in any case it is not that useful to create and manage views which are extremely large, better to split up views in that case. On Fri, Jun 28, 2013 at 3:00 PM, Juan Manuel Alcantara < jmalcant...@apunto.com.mx> wrote: > I was thinking about cases in which the resulting view is extremely large, > but I agree it makes sense to have just one option to download all the data. > The way I've worked around this limitation is setting the number of rows > per page to allow all the records to be displayed in a single page, this > works well with views that return a moderate number of records. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1170104 > > Title: > SQL View: Downloads only include rows from the current page > > Status in DHIS 2 - District Health Information Software: > New > > Bug description: > When downloading an sql view to Excel or CSV only the rows included on > the current page are downloaded (if the result set is paged over > multiple pages). This is very confusing. We should get all values/rows > in the result set into the downloaded file. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/dhis2/+bug/1170104/+subscriptions > -- You received this bug notification because you are a member of DHIS 2 developers, which is subscribed to DHIS. https://bugs.launchpad.net/bugs/1170104 Title: SQL View: Downloads only include rows from the current page Status in DHIS 2 - District Health Information Software: New Bug description: When downloading an sql view to Excel or CSV only the rows included on the current page are downloaded (if the result set is paged over multiple pages). This is very confusing. We should get all values/rows in the result set into the downloaded file. To manage notifications about this bug go to: https://bugs.launchpad.net/dhis2/+bug/1170104/+subscriptions ___ 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
Re: [Dhis2-devs] [Dhis2-users] dhis to submit anonymous data
Hi Lars, I think it is important to get it right from the beginning. following the lead of other big open source projects. It is critical to remember that many of the organisations using DHIS2 are governments, and there could be some possible sensitivies about the DHIS core team collecting any sort of information. Before you go too far with this, I would think it would be good to identify what the purpose (which you mention) of collecting any data would be, and spell it out very clearly, and why opting out would not be an option. I would also be clear about all of the legal technicalities, including what county's law would regulate the collection of such information. Even if you were not to collect the IP's, there is of course always the possibility that they could be collected upstream. This might not be directly the core team's worry, but it might be. Regards, Jason On Fri, Jun 28, 2013 at 2:35 PM, Lars Helge Øverland wrote: > Hi, > > thanks for the good questions and comments. > > This information will be stored in some central system. The system will be > managed by the DHIS core team. That system will be made open source so that > anyone who feels like it could investigate it. > > >> Who would have access to the "sensitive" data like IP addresses of the >> servers, i.e. the data which would not be publicly disclosed? Given recent >> revelations in the news, how would possible data requests from third >> parties be handled (such as a list of IP addresses for where DHIS2 is used)? >> >> > We will simply not store IP addresses. We are not interested in them > anyway, and to avoid any thinkable doubt of misuse or NSA inquiries we will > not store them. > > I am thinking that for this function to have a purpose, it should not be > possible to opt out of the very basic, anonymous data, like DHIS version > and random system identifier. If optional then the statistics wouldn't be > very useful. If that is not acceptable we would rather drop the feature. Of > course, the "activation" feature with contact person etc would be > completely optional and require that you actively enable it. > > One way to approach IP address security is to not record them anywhere >> (and make sure the central server to which the data is sent does not keep >> any log of them.) If the central server doesn't know the IP addresses, they >> can't be divulged to any third party. >> >> > Agreed. > > >> A very different approach to openness and security is taken by the >> optional OpenMRS "Atlas module". This opt-in module allows an OpenMRS >> installation to provide information that is available in a public OpenMRS >> "atlas" of implementations. The atlas can facilitate interactions between >> OpenMRS community members, including prospective members, and it also >> serves as publicity for OpenMRS as well as the implementers. I'll leave it >> for others to say whether DHIS2 administrators would feel comfortable or >> even welcome this kind of public information for their implementations. See >> http://openmrs.org/atlas/ for the OpenMRS atlas itself, and >> https://wiki.openmrs.org/display/docs/Atlas+Module+User+Guide for the >> atlas module user guide. >> > > Thanks for the tip, I will check out the atlas module for inspiration. > > Another idea for this concept: The DHIS instances could be checking with a > central system whether new major versions of DHIS are available for > download or whether any critical bugfixes are available for the current > major version. This notifications could be made available through the DHIS > messaging system and be sent to some group of system admin users. > > > More comments are welcome. > > cheers > > Lars > > ___ 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
Re: [Dhis2-devs] [Dhis2-users] dhis to submit anonymous data
I agree with Jason on all counts so won't repeat them. A mandatory "ET call home" feature would not and should not be generally acceptable. Besides which its not too clear how, or more pertinently, when, this exchange will happen. On first boot? Every boot. Periodically? Anyway I don't like it and also worry that these things have a nasty habit of leading to scope creep. I think the idea of periodically scanning for releases and updates is good. Also planning to integrate such behaviour in dhis2-tools. Bob On 28 June 2013 15:01, Jason Pickering wrote: > Hi Lars, > > I think it is important to get it right from the beginning. following the > lead of other big open source projects. It is critical to remember that > many of the organisations using DHIS2 are governments, and there could be > some possible sensitivies about the DHIS core team collecting any sort of > information. > > Before you go too far with this, I would think it would be good to > identify what the purpose (which you mention) of collecting any data would > be, and spell it out very clearly, and why opting out would not be an > option. I would also be clear about all of the legal technicalities, > including what county's law would regulate the collection of such > information. > > Even if you were not to collect the IP's, there is of course always the > possibility that they could be collected upstream. This might not be > directly the core team's worry, but it might be. > > Regards, > Jason > > > > > On Fri, Jun 28, 2013 at 2:35 PM, Lars Helge Øverland > wrote: > >> Hi, >> >> thanks for the good questions and comments. >> >> This information will be stored in some central system. The system will >> be managed by the DHIS core team. That system will be made open source so >> that anyone who feels like it could investigate it. >> >> >>> Who would have access to the "sensitive" data like IP addresses of the >>> servers, i.e. the data which would not be publicly disclosed? Given recent >>> revelations in the news, how would possible data requests from third >>> parties be handled (such as a list of IP addresses for where DHIS2 is used)? >>> >>> >> We will simply not store IP addresses. We are not interested in them >> anyway, and to avoid any thinkable doubt of misuse or NSA inquiries we will >> not store them. >> >> I am thinking that for this function to have a purpose, it should not be >> possible to opt out of the very basic, anonymous data, like DHIS version >> and random system identifier. If optional then the statistics wouldn't be >> very useful. If that is not acceptable we would rather drop the feature. Of >> course, the "activation" feature with contact person etc would be >> completely optional and require that you actively enable it. >> >> One way to approach IP address security is to not record them anywhere >>> (and make sure the central server to which the data is sent does not keep >>> any log of them.) If the central server doesn't know the IP addresses, they >>> can't be divulged to any third party. >>> >>> >> Agreed. >> >> >>> A very different approach to openness and security is taken by the >>> optional OpenMRS "Atlas module". This opt-in module allows an OpenMRS >>> installation to provide information that is available in a public OpenMRS >>> "atlas" of implementations. The atlas can facilitate interactions between >>> OpenMRS community members, including prospective members, and it also >>> serves as publicity for OpenMRS as well as the implementers. I'll leave it >>> for others to say whether DHIS2 administrators would feel comfortable or >>> even welcome this kind of public information for their implementations. See >>> http://openmrs.org/atlas/ for the OpenMRS atlas itself, and >>> https://wiki.openmrs.org/display/docs/Atlas+Module+User+Guide for the >>> atlas module user guide. >>> >> >> Thanks for the tip, I will check out the atlas module for inspiration. >> >> Another idea for this concept: The DHIS instances could be checking with >> a central system whether new major versions of DHIS are available for >> download or whether any critical bugfixes are available for the current >> major version. This notifications could be made available through the DHIS >> messaging system and be sent to some group of system admin users. >> >> >> More comments are welcome. >> >> cheers >> >> Lars >> >> > > ___ > Mailing list: https://launchpad.net/~dhis2-users > Post to : dhis2-us...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-users > More help : https://help.launchpad.net/ListHelp > > ___ 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
[Dhis2-devs] [GSoC] DHIS2 Android application project branch and blog
Hi, I've created branch for Android project and also a blog where I'll make a weekly post highlighting the progress of development. Branch: https://code.launchpad.net/~araz-abishov-gsoc/dhis2/dhis2-android-app Blog: http://arazabishov.wordpress.com I apologize for being late with creating branch and blog. It took bit of time to study bazaar. Nevertheless, android app development is on schedule. Regards Araz ___ 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
Re: [Dhis2-devs] Orphaned orgunits during creation of a new orgunit
Hi Lars, This issue is continuing to plague our installations, even on 2.12. Could we add some sort of warning like "Are you sure you want to add a new root?" when people attempt to add a new root? After a recent training, we ended up with about 10 new roots, which was absolutely not the intention of the users. Regards, Jason On Mon, Aug 20, 2012 at 3:10 PM, Lars Helge Øverland wrote: > Hi Jason, thanks for the report. I have tested a bit and maybe found the > error. > > Currently the org unit tree only allows you to unselect by clicking on > the root org unit (you cannot unselect by clicking on any other org > unit in the tree). This was done to make it possible to create > multiple roots in the tree. A user assigned to the root can see all > new roots being made. > > An unwanted effect of this is that a user assigned to an org unit > lower in the tree (e.g. a district) can also unselect the current org > unit by clicking on that district. So when creating a new org unit, > after unselecting the current org unit, it will be created at the same > level as the district. But the user is only assigned to the district > and is thus prohibited to see other org units at the same level - > giving the impression that the newly created org unit disappeared in > thin air. > > The fix to this problem is to only allow unselect of org units for the > root of the full org unit hierarchy, not for the "virtual" root that > has been assigned to users lower in three. Will be fixed and > backported. > > Lars > > > On Fri, Aug 17, 2012 at 6:51 AM, Jason Pickering > wrote: >> Hi Devs, >> >> I do not have an exact procedure to recreate this bug, but it has >> been reported numerous times by different users which attempt to >> create an orgunit as a child of an existing orgunit. For some reason >> (perhaps related to a bad internet connection but no clue really) . I >> can verify that a new "root" orgunit will be created with a NULL >> parentid. However, in version 2.8 the newly created root orgunit >> (which should be a child of an existing orgunit) does not appear. >> Since I cannot define a procedure for this to happen, I cannot really >> report this as a bug, but wanted to bring it up for discussion and see >> if maybe a warning could be added if the parentID is NULL. This is >> such an uncommon operation, that it might help to justify such a >> warning. >> >> Best regards, >> Jason >> >> ___ >> 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 ___ 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
Re: [Dhis2-devs] [Dhis2-users] dhis to submit anonymous data
Okay thanks for feedback. To clarify, for the "calling home" part we will only collect the DHIS 2 version (no IP, no Java version etc). In other words we will only register that there exists a DHIS version out there with a given version. It will not be possible to track it back to the IP. Then, what confuses me is; how could the fact that a government uses DHIS 2 as their health system possibly be sensitive information or violate country laws? It will already be a public Internet facing system, which could be revealed through a google search; and with likely thousands of users, knowing of its existence. On Fri, Jun 28, 2013 at 5:24 PM, Bob Jolliffe wrote: > I agree with Jason on all counts so won't repeat them. > > A mandatory "ET call home" feature would not and should not be generally > acceptable. Besides which its not too clear how, or more pertinently, > when, this exchange will happen. On first boot? Every boot. Periodically? > > Anyway I don't like it and also worry that these things have a nasty habit > of leading to scope creep. > > I think the idea of periodically scanning for releases and updates is > good. Also planning to integrate such behaviour in dhis2-tools. > > Bob > > > > On 28 June 2013 15:01, Jason Pickering wrote: > >> Hi Lars, >> >> I think it is important to get it right from the beginning. following the >> lead of other big open source projects. It is critical to remember that >> many of the organisations using DHIS2 are governments, and there could be >> some possible sensitivies about the DHIS core team collecting any sort of >> information. >> >> Before you go too far with this, I would think it would be good to >> identify what the purpose (which you mention) of collecting any data would >> be, and spell it out very clearly, and why opting out would not be an >> option. I would also be clear about all of the legal technicalities, >> including what county's law would regulate the collection of such >> information. >> >> Even if you were not to collect the IP's, there is of course always the >> possibility that they could be collected upstream. This might not be >> directly the core team's worry, but it might be. >> >> Regards, >> Jason >> >> >> >> >> On Fri, Jun 28, 2013 at 2:35 PM, Lars Helge Øverland > > wrote: >> >>> Hi, >>> >>> thanks for the good questions and comments. >>> >>> This information will be stored in some central system. The system will >>> be managed by the DHIS core team. That system will be made open source so >>> that anyone who feels like it could investigate it. >>> >>> Who would have access to the "sensitive" data like IP addresses of the servers, i.e. the data which would not be publicly disclosed? Given recent revelations in the news, how would possible data requests from third parties be handled (such as a list of IP addresses for where DHIS2 is used)? >>> We will simply not store IP addresses. We are not interested in them >>> anyway, and to avoid any thinkable doubt of misuse or NSA inquiries we will >>> not store them. >>> >>> I am thinking that for this function to have a purpose, it should not be >>> possible to opt out of the very basic, anonymous data, like DHIS version >>> and random system identifier. If optional then the statistics wouldn't be >>> very useful. If that is not acceptable we would rather drop the feature. Of >>> course, the "activation" feature with contact person etc would be >>> completely optional and require that you actively enable it. >>> >>> One way to approach IP address security is to not record them anywhere (and make sure the central server to which the data is sent does not keep any log of them.) If the central server doesn't know the IP addresses, they can't be divulged to any third party. >>> Agreed. >>> >>> A very different approach to openness and security is taken by the optional OpenMRS "Atlas module". This opt-in module allows an OpenMRS installation to provide information that is available in a public OpenMRS "atlas" of implementations. The atlas can facilitate interactions between OpenMRS community members, including prospective members, and it also serves as publicity for OpenMRS as well as the implementers. I'll leave it for others to say whether DHIS2 administrators would feel comfortable or even welcome this kind of public information for their implementations. See http://openmrs.org/atlas/ for the OpenMRS atlas itself, and https://wiki.openmrs.org/display/docs/Atlas+Module+User+Guide for the atlas module user guide. >>> >>> Thanks for the tip, I will check out the atlas module for inspiration. >>> >>> Another idea for this concept: The DHIS instances could be checking with >>> a central system whether new major versions of DHIS are available for >>> download or whether any critical bugfixes are available for the current >>> major version. This notifications could b
Re: [Dhis2-devs] Orphaned orgunits during creation of a new orgunit
Yes, no problem, we can do this. https://blueprints.launchpad.net/dhis2/+spec/warning-root-org-unit On Fri, Jun 28, 2013 at 5:34 PM, Jason Pickering < jason.p.picker...@gmail.com> wrote: > Hi Lars, > This issue is continuing to plague our installations, even on 2.12. > Could we add some sort of warning like "Are you sure you want to add a > new root?" when people attempt to add a new root? After a recent > training, we ended up with about 10 new roots, which was absolutely > not the intention of the users. > > Regards, > Jason > > > On Mon, Aug 20, 2012 at 3:10 PM, Lars Helge Øverland > wrote: > > Hi Jason, thanks for the report. I have tested a bit and maybe found the > error. > > > > Currently the org unit tree only allows you to unselect by clicking on > > the root org unit (you cannot unselect by clicking on any other org > > unit in the tree). This was done to make it possible to create > > multiple roots in the tree. A user assigned to the root can see all > > new roots being made. > > > > An unwanted effect of this is that a user assigned to an org unit > > lower in the tree (e.g. a district) can also unselect the current org > > unit by clicking on that district. So when creating a new org unit, > > after unselecting the current org unit, it will be created at the same > > level as the district. But the user is only assigned to the district > > and is thus prohibited to see other org units at the same level - > > giving the impression that the newly created org unit disappeared in > > thin air. > > > > The fix to this problem is to only allow unselect of org units for the > > root of the full org unit hierarchy, not for the "virtual" root that > > has been assigned to users lower in three. Will be fixed and > > backported. > > > > Lars > > > > > > On Fri, Aug 17, 2012 at 6:51 AM, Jason Pickering > > wrote: > >> Hi Devs, > >> > >> I do not have an exact procedure to recreate this bug, but it has > >> been reported numerous times by different users which attempt to > >> create an orgunit as a child of an existing orgunit. For some reason > >> (perhaps related to a bad internet connection but no clue really) . I > >> can verify that a new "root" orgunit will be created with a NULL > >> parentid. However, in version 2.8 the newly created root orgunit > >> (which should be a child of an existing orgunit) does not appear. > >> Since I cannot define a procedure for this to happen, I cannot really > >> report this as a bug, but wanted to bring it up for discussion and see > >> if maybe a warning could be added if the parentID is NULL. This is > >> such an uncommon operation, that it might help to justify such a > >> warning. > >> > >> Best regards, > >> Jason > >> > >> ___ > >> 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 > ___ 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
[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 11280: Removed pointless css
revno: 11280
committer: Lars Helge Øverland
branch nick: dhis2
timestamp: Fri 2013-06-28 18:06:11 +0200
message:
Removed pointless css
modified:
dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/green/green.css
dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/india/india.css
dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/light_blue/light_blue.css
dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/vietnam/vietnam.css
--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk
Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription
=== modified file 'dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/green/green.css'
--- dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/green/green.css 2013-05-22 13:50:17 +
+++ dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/green/green.css 2013-06-28 16:06:11 +
@@ -246,7 +246,6 @@
background-color: #4a6f4d;
height: 535px;
width: 235px;
- float: left;
position: absolute;
top: 44px;
left: 0px;
@@ -260,7 +259,6 @@
#leftBarContents
{
- color: black;
font-size: 12px;
}
=== modified file 'dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/india/india.css'
--- dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/india/india.css 2013-05-27 08:39:36 +
+++ dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/india/india.css 2013-06-28 16:06:11 +
@@ -267,7 +267,6 @@
background-color: #518a0f;
height: 535px;
width: 235px;
- float: left;
position: absolute;
top: 46px;
left: 0px;
@@ -281,7 +280,6 @@
#leftBarContents
{
- color: black;
font-size: 12px;
}
=== modified file 'dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/light_blue/light_blue.css'
--- dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/light_blue/light_blue.css 2013-05-22 13:50:17 +
+++ dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/light_blue/light_blue.css 2013-06-28 16:06:11 +
@@ -247,7 +247,6 @@
background-color: #1f5489;
height: 535px;
width: 235px;
- float: left;
position: absolute;
top: 44px;
left: 0px;
@@ -261,7 +260,6 @@
#leftBarContents
{
- color: black;
font-size: 12px;
}
=== modified file 'dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/vietnam/vietnam.css'
--- dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/vietnam/vietnam.css 2012-10-19 10:20:05 +
+++ dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/vietnam/vietnam.css 2013-06-28 16:06:11 +
@@ -246,13 +246,12 @@
background-color: #b91010;
height: 535px;
width: 235px;
- float: left;
position: absolute;
top: 46px;
left: 0px;
padding-top: 6px;
- border-right: 1px solid #10375f;
- border-bottom: 1px solid #10375f;
+ border-right: 1px solid #aaa;
+ border-bottom: 1px solid #aaa;
filter: alpha(opacity=90);
opacity: 0.90;
border-bottom-right-radius: 5px;
@@ -260,7 +259,6 @@
#leftBarContents
{
- color: black;
font-size: 12px;
}
___
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
Re: [Dhis2-devs] [Dhis2-users] dhis to submit anonymous data
Perhaps it could be modeled after the Drupal Update Stats module. This module generates simple stats that can be seen here. https://drupal.org/project/usage/drupal you can read more about it here. https://drupal.org/node/329620 I'd also support a slightly more detailed optional submission as well that does send OS, Java version, Web Server and database server, though rather than it being a service that runs in the background there would be a submit button on the About DHIS2 page. So it would be very clear what information was being submitted and when that information was being submitted. This information would be very help for the development team to have a clear idea of the target DHIS2 environments and make sure they are properly supported. Dan On Jun 28, 2013, at 11:54 AM, Lars Helge Øverland wrote: > Okay thanks for feedback. > > To clarify, for the "calling home" part we will only collect the DHIS 2 > version (no IP, no Java version etc). In other words we will only register > that there exists a DHIS version out there with a given version. It will not > be possible to track it back to the IP. > > Then, what confuses me is; how could the fact that a government uses DHIS 2 > as their health system possibly be sensitive information or violate country > laws? It will already be a public Internet facing system, which could be > revealed through a google search; and with likely thousands of users, knowing > of its existence. > > > > > > > > > On Fri, Jun 28, 2013 at 5:24 PM, Bob Jolliffe wrote: > I agree with Jason on all counts so won't repeat them. > > A mandatory "ET call home" feature would not and should not be generally > acceptable. Besides which its not too clear how, or more pertinently, when, > this exchange will happen. On first boot? Every boot. Periodically? > > Anyway I don't like it and also worry that these things have a nasty habit of > leading to scope creep. > > I think the idea of periodically scanning for releases and updates is good. > Also planning to integrate such behaviour in dhis2-tools. > > Bob > > > > On 28 June 2013 15:01, Jason Pickering wrote: > Hi Lars, > > I think it is important to get it right from the beginning. following the > lead of other big open source projects. It is critical to remember that many > of the organisations using DHIS2 are governments, and there could be some > possible sensitivies about the DHIS core team collecting any sort of > information. > > Before you go too far with this, I would think it would be good to identify > what the purpose (which you mention) of collecting any data would be, and > spell it out very clearly, and why opting out would not be an option. I > would also be clear about all of the legal technicalities, including what > county's law would regulate the collection of such information. > > Even if you were not to collect the IP's, there is of course always the > possibility that they could be collected upstream. This might not be directly > the core team's worry, but it might be. > > Regards, > Jason > > > > > On Fri, Jun 28, 2013 at 2:35 PM, Lars Helge Øverland > wrote: > Hi, > > thanks for the good questions and comments. > > This information will be stored in some central system. The system will be > managed by the DHIS core team. That system will be made open source so that > anyone who feels like it could investigate it. > >> Who would have access to the "sensitive" data like IP addresses of the >> servers, i.e. the data which would not be publicly disclosed? Given recent >> revelations in the news, how would possible data requests from third parties >> be handled (such as a list of IP addresses for where DHIS2 is used)? > > > We will simply not store IP addresses. We are not interested in them anyway, > and to avoid any thinkable doubt of misuse or NSA inquiries we will not store > them. > > I am thinking that for this function to have a purpose, it should not be > possible to opt out of the very basic, anonymous data, like DHIS version and > random system identifier. If optional then the statistics wouldn't be very > useful. If that is not acceptable we would rather drop the feature. Of > course, the "activation" feature with contact person etc would be completely > optional and require that you actively enable it. > > One way to approach IP address security is to not record them anywhere (and > make sure the central server to which the data is sent does not keep any log > of them.) If the central server doesn't know the IP addresses, they can't be > divulged to any third party. > > > Agreed. > > A very different approach to openness and security is taken by the optional > OpenMRS "Atlas module". This opt-in module allows an OpenMRS installation to > provide information that is available in a public OpenMRS "atlas" of > implementations. The atlas can facilitate interactions between OpenMRS > community members, includi
Re: [Dhis2-devs] [Dhis2-users] dhis to submit anonymous data
Agree with Dan that a submit button on the about page (which previewed the information that would be sent) is better than ET calling home. Though we need to remain clear about the usage distinction of sharing with developers and feeding a more public repo. Need to think a bit more. On 28 June 2013 17:10, Dan Cocos wrote: > Perhaps it could be modeled after the Drupal Update Stats module. This > module generates simple stats that can be seen here. > https://drupal.org/project/usage/drupal you can read more about it here. > https://drupal.org/node/329620 > > I'd also support a slightly more detailed optional submission as well that > does send OS, Java version, Web Server and database server, though rather > than it being a service that runs in the background there would be a submit > button on the About DHIS2 page. So it would be very clear what information > was being submitted and when that information was being submitted. This > information would be very help for the development team to have a clear > idea of the target DHIS2 environments and make sure they are properly > supported. > > Dan > > On Jun 28, 2013, at 11:54 AM, Lars Helge Øverland > wrote: > > Okay thanks for feedback. > > To clarify, for the "calling home" part we will only collect the DHIS 2 > version (no IP, no Java version etc). In other words we will only register > that there exists a DHIS version out there with a given version. It will > not be possible to track it back to the IP. > > Then, what confuses me is; how could the fact that a government uses DHIS > 2 as their health system possibly be sensitive information or violate > country laws? It will already be a public Internet facing system, which > could be revealed through a google search; and with likely thousands of > users, knowing of its existence. > > > > > > > > > On Fri, Jun 28, 2013 at 5:24 PM, Bob Jolliffe wrote: > >> I agree with Jason on all counts so won't repeat them. >> >> A mandatory "ET call home" feature would not and should not be generally >> acceptable. Besides which its not too clear how, or more pertinently, >> when, this exchange will happen. On first boot? Every boot. Periodically? >> >> Anyway I don't like it and also worry that these things have a nasty >> habit of leading to scope creep. >> >> I think the idea of periodically scanning for releases and updates is >> good. Also planning to integrate such behaviour in dhis2-tools. >> >> Bob >> >> >> >> On 28 June 2013 15:01, Jason Pickering wrote: >> >>> Hi Lars, >>> >>> I think it is important to get it right from the beginning. following >>> the lead of other big open source projects. It is critical to remember that >>> many of the organisations using DHIS2 are governments, and there could be >>> some possible sensitivies about the DHIS core team collecting any sort of >>> information. >>> >>> Before you go too far with this, I would think it would be good to >>> identify what the purpose (which you mention) of collecting any data would >>> be, and spell it out very clearly, and why opting out would not be an >>> option. I would also be clear about all of the legal technicalities, >>> including what county's law would regulate the collection of such >>> information. >>> >>> Even if you were not to collect the IP's, there is of course always the >>> possibility that they could be collected upstream. This might not be >>> directly the core team's worry, but it might be. >>> >>> Regards, >>> Jason >>> >>> >>> >>> >>> On Fri, Jun 28, 2013 at 2:35 PM, Lars Helge Øverland < >>> larshe...@gmail.com> wrote: >>> Hi, thanks for the good questions and comments. This information will be stored in some central system. The system will be managed by the DHIS core team. That system will be made open source so that anyone who feels like it could investigate it. > Who would have access to the "sensitive" data like IP addresses of > the servers, i.e. the data which would not be publicly disclosed? Given > recent revelations in the news, how would possible data requests from > third > parties be handled (such as a list of IP addresses for where DHIS2 is > used)? > > We will simply not store IP addresses. We are not interested in them anyway, and to avoid any thinkable doubt of misuse or NSA inquiries we will not store them. I am thinking that for this function to have a purpose, it should not be possible to opt out of the very basic, anonymous data, like DHIS version and random system identifier. If optional then the statistics wouldn't be very useful. If that is not acceptable we would rather drop the feature. Of course, the "activation" feature with contact person etc would be completely optional and require that you actively enable it. One way to approach IP address security is to not record them anywhere > (and make sure the central server to which the data is sent
[Dhis2-devs] Running DHIS 2.12 after migration
Dears! I had one DHIS 2.10 running fine on linode. But I had to migrate it to Maputo because of the price just moving a pg_dumped file. In Maputo I placed the same DHIS2 version. Then upgraded to DHIS 2.11 and then 2.12. I had run mrs datamart and the analytics. No erros were reported on the logs and seems so far so good. My old reports a listed (all are jasper using directly the aggregateddatavalue) works fine. The problem is on "Data Visualizer". I define the graph parameters but when I click on update a small window without any text pops up. No errors, warnings, info comes on the logs. What can I do? Orva ___ 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
Re: [Dhis2-devs] [Dhis2-users] dhis to submit anonymous data
Hi Lars, What I mean by the IP being collected, is it "might" be collected (unless you are careful) by your reverse proxy or upstream providers. Even though whatever protocol you might come up with might not collect it, it would require you to purposefully NOT collect it though unintentional means, such as through the logs of your upstream proxies or by your ISP. Additionally, I think it needs to be crystal clear who the "DHIS core team" is, under what laws they operate, and how it can be certified that such information is not being collected (other than just saying that it is not being done). I think the fact that many ministries and governments use DHIS2 is particularly relevant in this case, because I have run up against a lot of distrust of the whole cloud computing model which many implementers (including myself) are using. Adding the possible collection of any data by the "DHIS core team" to this, could further complicate already long negotiations on the issue of hosting. Although the data which DHIS2 collects is generally not regarded to be secret, there have been instances of which I personally know of, in which this is the case. Since you have stated the information would be open-source, it would mean that potentially it could be used for research purposes, or other unknown (and possibly nefarious) purposes, which again, could complicate already sensitive discussions with some of the DHIS2 users. So, I think until you make clear exactly what is going to done with the data, who will manage and protect it, I think the "opt in" model would be the only really feasible option, and even then, make it exactly clear what is going to be submitted and to whom and for what purpose. Regards, Jason On Fri, Jun 28, 2013 at 6:21 PM, Bob Jolliffe wrote: > Agree with Dan that a submit button on the about page (which previewed the > information that would be sent) is better than ET calling home. > > Though we need to remain clear about the usage distinction of sharing with > developers and feeding a more public repo. Need to think a bit more. > > > On 28 June 2013 17:10, Dan Cocos wrote: > >> Perhaps it could be modeled after the Drupal Update Stats module. This >> module generates simple stats that can be seen here. >> https://drupal.org/project/usage/drupal you can read more about it here. >> https://drupal.org/node/329620 >> >> I'd also support a slightly more detailed optional submission as well >> that does send OS, Java version, Web Server and database server, though >> rather than it being a service that runs in the background there would be a >> submit button on the About DHIS2 page. So it would be very clear what >> information was being submitted and when that information was being >> submitted. This information would be very help for the development team to >> have a clear idea of the target DHIS2 environments and make sure they are >> properly supported. >> >> Dan >> >> On Jun 28, 2013, at 11:54 AM, Lars Helge Øverland >> wrote: >> >> Okay thanks for feedback. >> >> To clarify, for the "calling home" part we will only collect the DHIS 2 >> version (no IP, no Java version etc). In other words we will only register >> that there exists a DHIS version out there with a given version. It will >> not be possible to track it back to the IP. >> >> Then, what confuses me is; how could the fact that a government uses DHIS >> 2 as their health system possibly be sensitive information or violate >> country laws? It will already be a public Internet facing system, which >> could be revealed through a google search; and with likely thousands of >> users, knowing of its existence. >> >> >> >> >> >> >> >> >> On Fri, Jun 28, 2013 at 5:24 PM, Bob Jolliffe wrote: >> >>> I agree with Jason on all counts so won't repeat them. >>> >>> A mandatory "ET call home" feature would not and should not be generally >>> acceptable. Besides which its not too clear how, or more pertinently, >>> when, this exchange will happen. On first boot? Every boot. Periodically? >>> >>> Anyway I don't like it and also worry that these things have a nasty >>> habit of leading to scope creep. >>> >>> I think the idea of periodically scanning for releases and updates is >>> good. Also planning to integrate such behaviour in dhis2-tools. >>> >>> Bob >>> >>> >>> >>> On 28 June 2013 15:01, Jason Pickering wrote: >>> Hi Lars, I think it is important to get it right from the beginning. following the lead of other big open source projects. It is critical to remember that many of the organisations using DHIS2 are governments, and there could be some possible sensitivies about the DHIS core team collecting any sort of information. Before you go too far with this, I would think it would be good to identify what the purpose (which you mention) of collecting any data would be, and spell it out very clearly, and why opting out would not be an option. I would also be clear about all
[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 11281: Improved left side menu, cleaner and more modern look
revno: 11281
committer: Lars Helge Øverland
branch nick: dhis2
timestamp: Fri 2013-06-28 20:14:34 +0200
message:
Improved left side menu, cleaner and more modern look
modified:
dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/green/green.css
dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/light_blue/light_blue.css
dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/widgets.css
dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-datadictionary/src/main/webapp/dhis-web-maintenance-datadictionary/menu.vm
--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk
Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription
=== modified file 'dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/green/green.css'
--- dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/green/green.css 2013-06-28 16:06:11 +
+++ dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/green/green.css 2013-06-28 18:14:34 +
@@ -243,59 +243,50 @@
#leftBar
{
- background-color: #4a6f4d;
- height: 535px;
+ height: 580px;
width: 235px;
position: absolute;
- top: 44px;
+ top: 46px;
left: 0px;
padding-top: 6px;
- border-right: 1px solid #ccc;
- border-bottom: 1px solid #ccc;
- filter: alpha(opacity=90);
- opacity: 0.90;
- border-bottom-right-radius: 5px;
+ border-right: 1px solid #ececec;
}
#leftBarContents
{
- font-size: 12px;
+ font-size: 9pt;
}
#leftBarContents h2
{
- font-size: 10px;
- text-transform: uppercase;
- background-color: #679a6d;
- margin: 16px 15px 0px 15px;
- padding: 7px 0px 5px 11px;
- color: white;
+ font-size: 9pt;
+ margin: 16px 20px 2px 20px;
+ padding: 7px 0 7px 0;
font-weight: normal;
- border-radius: 3px;
+ font-family: LiberationSansBold, arial;
}
#leftBarContents ul
{
- margin-left: 26px;
list-style-type: none;
- color: white;
-}
-
-#leftBarContents li
-{
- padding-top: 3px;
- padding-bottom: 3px;
-}
-
-#leftBarContents a
-{
- color: white;
+ padding: 0;
+ margin: 0 20px 0 20px;
+}
+
+#leftBarContents ul a
+{
+ display: block;
+ color: #333;
text-decoration: none;
+ padding-top: 8px;
+ padding-bottom: 8px;
+ cursor: pointer;
+ border-bottom: 1px solid #ececec;
}
#leftBarContents a:hover
{
- color: #acc8de;
+ text-decoration: underline;
}
/**/
=== modified file 'dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/light_blue/light_blue.css'
--- dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/light_blue/light_blue.css 2013-06-28 16:06:11 +
+++ dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/light_blue/light_blue.css 2013-06-28 18:14:34 +
@@ -244,59 +244,50 @@
#leftBar
{
- background-color: #1f5489;
- height: 535px;
+ height: 580px;
width: 235px;
position: absolute;
- top: 44px;
+ top: 46px;
left: 0px;
padding-top: 6px;
- border-right: 1px solid #bbb;
- border-bottom: 1px solid #bbb;
- filter: alpha(opacity=90);
- opacity: 0.90;
- border-bottom-right-radius: 5px;
+ border-right: 1px solid #ececec;
}
#leftBarContents
{
- font-size: 12px;
+ font-size: 9pt;
}
#leftBarContents h2
{
- font-size: 10px;
- text-transform: uppercase;
- background-color: #4a89ba;
- margin: 16px 15px 0px 15px;
- padding: 7px 0px 5px 11px;
- color: white;
+ font-size: 9pt;
+ margin: 16px 20px 2px 20px;
+ padding: 7px 0 7px 0;
font-weight: normal;
- border-radius: 3px;
+ font-family: LiberationSansBold, arial;
}
#leftBarContents ul
{
- margin-left: 26px;
list-style-type: none;
- color: white;
-}
-
-#leftBarContents li
-{
- padding-top: 3px;
- padding-bottom: 3px;
-}
-
-#leftBarContents a
-{
- color: white;
+ padding: 0;
+ margin: 0 20px 0 20px;
+}
+
+#leftBarContents ul a
+{
+ display: block;
+ color: #333;
text-decoration: none;
+ padding-top: 8px;
+ padding-bottom: 8px;
+ cursor: pointer;
+ border-bottom: 1px solid #ececec;
}
#leftBarContents a:hover
{
- color: #acc8de;
+ text-decoration: underline;
}
/**/
=== modified file 'dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/widgets.css'
--- dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/widgets.css 2013-05-03 15:06:31 +
+++ dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/css/widgets.css 2013-06-28 18:14:34 +
@@ -141,18 +141,19 @@
div#orgUnitTree
{
- font-size: 9pt; /* Size to change */
+ fo
[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 11282: Light module, sorting of data sets
revno: 11282 committer: Lars Helge Øverland branch nick: dhis2 timestamp: Fri 2013-06-28 21:06:47 +0200 message: Light module, sorting of data sets modified: dhis-2/dhis-web/dhis-web-light/src/main/java/org/hisp/dhis/light/dataentry/action/GetDataSetsAction.java -- lp:dhis2 https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk Your team DHIS 2 developers is subscribed to branch lp:dhis2. To unsubscribe from this branch go to https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription === modified file 'dhis-2/dhis-web/dhis-web-light/src/main/java/org/hisp/dhis/light/dataentry/action/GetDataSetsAction.java' --- dhis-2/dhis-web/dhis-web-light/src/main/java/org/hisp/dhis/light/dataentry/action/GetDataSetsAction.java 2012-01-23 10:49:32 + +++ dhis-2/dhis-web/dhis-web-light/src/main/java/org/hisp/dhis/light/dataentry/action/GetDataSetsAction.java 2013-06-28 19:06:47 + @@ -29,12 +29,14 @@ import com.opensymphony.xwork2.Action; import org.apache.commons.lang.Validate; +import org.hisp.dhis.common.comparator.IdentifiableObjectNameComparator; import org.hisp.dhis.dataset.DataSet; import org.hisp.dhis.light.utils.FormUtils; import org.hisp.dhis.organisationunit.OrganisationUnit; import org.hisp.dhis.organisationunit.OrganisationUnitService; import java.util.ArrayList; +import java.util.Collections; import java.util.List; /** @@ -114,6 +116,8 @@ dataSets = formUtils.getDataSetsForCurrentUser( organisationUnitId ); +Collections.sort( dataSets, IdentifiableObjectNameComparator.INSTANCE ); + organisationUnit = organisationUnitService.getOrganisationUnit( organisationUnitId ); if ( dataSets.size() == 1 ) ___ 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
[Dhis2-devs] [Bug 1195858] [NEW] Light module displays current period in data entry
Public bug reported: Light module displays current module in data entry. It must not allow data entry for current period (unless if set differently through the data set option) and be consistent with web data entry module. ** Affects: dhis2 Importance: Medium Assignee: Lars Helge Øverland (larshelge) Status: New ** Changed in: dhis2 Milestone: None => 2.12 ** Changed in: dhis2 Assignee: (unassigned) => Lars Helge Øverland (larshelge) ** Changed in: dhis2 Importance: Undecided => Medium -- You received this bug notification because you are a member of DHIS 2 developers, which is subscribed to DHIS. https://bugs.launchpad.net/bugs/1195858 Title: Light module displays current period in data entry Status in DHIS 2 - District Health Information Software: New Bug description: Light module displays current module in data entry. It must not allow data entry for current period (unless if set differently through the data set option) and be consistent with web data entry module. To manage notifications about this bug go to: https://bugs.launchpad.net/dhis2/+bug/1195858/+subscriptions ___ 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
