Re: [Dhis2-devs] [Dhis2-users] dhis version 2.30 is released

Lars and development team, we appreciate all the hard work that went into this release Regards Simon Muyambo From: Dhis2-users On Behalf Of Lars Helge Øverland Sent: Thursday, 12 July 2018 1:43 PM To: DHIS 2 Users list ; DHIS 2 Developers list Subject: [Dhis2-users] dhis version 2.30

Re: [Dhis2-devs] Cancelled event: University of Melbourne - DHIS 2 - VA Training @ Wed 29 Aug - Thu 30 Aug 2018 (dhis2-devs@lists.launchpad.net)

Apologies for the spam email, not intended audience. - - Busoye Anifalaje (PhD) Director of Services (Principal), BAO Systems UK: +44 7901-740-757 | US: +1 682-307-0986| bus...@baosystems.com | http://www.baosystems.com | Skype: b

[Dhis2-devs] Cancelled event: University of Melbourne - DHIS 2 - VA Training @ Wed 29 Aug - Thu 30 Aug 2018 (dhis2-devs@lists.launchpad.net)

BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:CANCEL BEGIN:VEVENT DTSTART;VALUE=DATE:20180829 DTEND;VALUE=DATE:20180831 DTSTAMP:20180712T181346Z ORGANIZER;CN=BAO Business Calendar:mailto:baosystems.com_4mesfto70f7hgfla0k o0qe8...@group.cale

[Dhis2-devs] Invitation: University of Melbourne - DHIS 2 - VA Training @ Wed 29 Aug - Thu 30 Aug 2018 (dhis2-devs@lists.launchpad.net)

BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART;VALUE=DATE:20180829 DTEND;VALUE=DATE:20180831 DTSTAMP:20180712T174344Z ORGANIZER;CN=BAO Business Calendar:mailto:baosystems.com_4mesfto70f7hgfla0k o0qe8...@group.cal

Re: [Dhis2-devs] dhis version 2.30 is released

Thanks Lars and team for the new features and functionalities in the platform. Regards, Dennis On Thu, 12 Jul 2018 at 14:43, Lars Helge Øverland wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

Morten Apology accepted - sometimes it's tricky to handle those curve-balls. In any case, there are some lessons here... ;-) Regards Calle On 12 July 2018 at 13:51, Morten Olav Hansen wrote: > Hi Calle > > I have only been aware of this bug for a few days (when it hit us in Lao), > and then w

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

The convention today is that resource tables are prefixed with an underscore, while analytics tables start with analytics*. As previously mentioned in this thread, changing this now will probably cause a lot of issues for existing scripts, so I think for now we should just avoid using tables starti

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

Agree that might have made sense at the start. But I think the priority now should be to rename that one table so that all the backup scripts in the wild get unbroken. Not to break them even more :-) On 12 July 2018 at 13:02, Knut Staring wrote: > Would be great if the convention could be that

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

Would be great if the convention could be that ALL generated tables (including analytics) started with an underscore. This convention is sort of already in place, just not applied consistently. Knut On Thu, Jul 12, 2018 at 6:05 PM Calle Hedberg wrote: > Hi > > I'm glad it's being addressed - bu

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

Hi Calle I have only been aware of this bug for a few days (when it hit us in Lao), and then we have both release and summer holidays going on. I agree the response is not ideal, but its not the easiest time for fixing bug issues. We are working hard on fixing this now (it might take 1-2 days), a

[Dhis2-devs] dhis version 2.30 is released

*Hi all,DHIS version 2.30 is out with many new features, apps and improvements.Login with admin/district on the demo system.ANALYTICS FEATURES---Linkable dashboards: Individual dashboards can now be linked to through the URL. This makes it easier to share dashboards th

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

Hi I'm glad it's being addressed - but I am less happy to hear you are aware of it but haven't said anything to the community... These type of bugs causes havoc, and waste a lot of time for users affected while they try to figure out what's gone wrong. There are two major lessons here: Firstly,

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

Ok, thanks Stian (no need to work on this then Viet) (knut, using pg_dump we normally filter away analytic* which means no period boundaries..) -- Morten Olav Hansen Senior Engineer, DHIS 2 University of Oslo http://www.dhis2.org On Thu, Jul 12, 2018 at 6:14 PM, Stian Sandvold wrote: > I have

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

I have started the work on renaming the table. I will update this thread as soon as I make progress. On Thu, Jul 12, 2018 at 12:17 PM, Morten Olav Hansen wrote: > Hi Knut > > I mean the main issue the thread was about... using maintenance => clear > analytic tables, it will delete analytics* whi

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

Right... I assume you could trigger that also through the API in order to continue to have backup scripts without manual intervention? On Thu, Jul 12, 2018, 4:47 PM Morten Olav Hansen wrote: > Hi Knut > > I mean the main issue the thread was about... using maintenance => clear > analytic tables,

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

Hi Knut I mean the main issue the thread was about... using maintenance => clear analytic tables, it will delete analytics* which includes the analytical boundaries. -- Morten Olav Hansen Senior Engineer, DHIS 2 University of Oslo http://www.dhis2.org On Thu, Jul 12, 2018 at 5:11 PM, Knut Star

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

Hi Morten, sorry but which functionality are you suggesting should not be used? What do you mean by manually deleting? Thanks, Knut On Thu, Jul 12, 2018, 4:23 PM Morten Olav Hansen wrote: > Hi Calle > > We are aware of this issue (actually it caused a problem with us in Lao), > for now.. I woul

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

Hi Calle We are aware of this issue (actually it caused a problem with us in Lao), for now.. I would also say don't use this functionality, its better to manually delete the analytics_* tables if you need it. We will rename that table soon we hope, and that should fix it (this also causes potentia

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

Bob, No response/action on the JIRA bug report yet - I guess most developers are on leave (wonderful summer here in Norway this year). Otherwise I agree, the name of that table does not fit the general naming convention as far as I can see. It would make more sense to call it e.g. "programindicat

Re: [Dhis2-devs] 2.29/2.30 WARNING - do not use Maintenance->ClearAnalyticsTables & parameter "-T analytics*" for database dumps

It would have been good if all the "dispensable" tables could rather have started with an underscore (though that again will of course break extant scripts). Knut On Thu, Jul 12, 2018, 1:27 PM Bob Jolliffe wrote: > Thats nasty alright. I guess using "-T anlytics_*" instead would > help. But t