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
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
Merge authors:
Jan Henrik Øverland (janhenrik-overland)
revno: 11275 [merge]
committer: Jan Henrik Overland janhenrik.overl...@gmail.com
branch nick: dhis2
timestamp: Fri 2013-06-28 12:43:28 +0200
message:
(PT) dx/dc/co issue fixed.
Merge authors:
Jan Henrik Øverland (janhenrik-overland)
revno: 11276 [merge]
committer: Jan Henrik Overland janhenrik.overl...@gmail.com
branch nick: dhis2
timestamp: Fri 2013-06-28 13:53:56 +0200
message:
(DV) Chart and api links
Merge authors:
Jan Henrik Øverland (janhenrik-overland)
revno: 11277 [merge]
committer: Jan Henrik Overland janhenrik.overl...@gmail.com
branch nick: dhis2
timestamp: Fri 2013-06-28 14:10:53 +0200
message:
(PT) Pivot table and api
Merge authors:
Jan Henrik Øverland (janhenrik-overland)
revno: 11278 [merge]
committer: Jan Henrik Overland janhenrik.overl...@gmail.com
branch nick: dhis2
timestamp: Fri 2013-06-28 14:12:09 +0200
message:
Minor fix.
modified:
** 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
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
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,
Merge authors:
Jan Henrik Øverland (janhenrik-overland)
revno: 11279 [merge]
committer: Jan Henrik Overland janhenrik.overl...@gmail.com
branch nick: dhis2
timestamp: Fri 2013-06-28 15:16:49 +0200
message:
(PT, DV) Detailed data
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 bobjolli...@gmail.com escribió:
Hi Juan
I think a lot of the Spanish
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
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
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
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
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
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,
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
revno: 11280
committer: Lars Helge Øverland larshe...@gmail.com
branch nick: dhis2
timestamp: Fri 2013-06-28 18:06:11 +0200
message:
Removed pointless css
modified:
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
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
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
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,
revno: 11281
committer: Lars Helge Øverland larshe...@gmail.com
branch nick: dhis2
timestamp: Fri 2013-06-28 20:14:34 +0200
message:
Improved left side menu, cleaner and more modern look
modified:
revno: 11282
committer: Lars Helge Øverland larshe...@gmail.com
branch nick: dhis2
timestamp: Fri 2013-06-28 21:06:47 +0200
message:
Light module, sorting of data sets
modified:
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
26 matches
Mail list logo
