Hi Markus,

Just following up my question below – is there any chance we could get this 
treated as a bug, and fixed in 2.26?  This issue has crippled 30-odd programs 
that Metrics for Management (M4M) has already published and deployed, but I’m 
guessing that the fix is probably just be a very simple string-handling change…

Many thanks for any help you might be able to give!

Cheers, Sam.


From: Dhis2-devs 
<dhis2-devs-bounces+samuel.johnson=qebo.co...@lists.launchpad.net> on behalf of 
Sam Johnson <samuel.john...@qebo.co.uk>
Date: Friday, 21 April 2017 at 17:58
To: Markus Bekken <mar...@dhis2.org>
Cc: Kenzo Fry <kenzo.fry.consult...@gmail.com>, Andrea Sprockett 
<and...@m4mgmt.org>, DHIS2 Developers <dhis2-devs@lists.launchpad.net>
Subject: Re: [Dhis2-devs] Many program rules not firing in 2.26


This sender failed our fraud detection checks and may not be who they appear to 
be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>

Feedback<http://aka.ms/SafetyTipsFeedback>

Hi Markus (and other devs),

Many thanks for diagnosing this so quickly.  You’re spot-on, it’s the dash in 
the source name that’s causing the rules to fail – if I remove dashes from all 
source names, the rules fire without problems.  In fact, this seems wider than 
just dashes – program rules that were failing in another instance seem to now 
work if I similarly remove brackets and spaces from source names.

Would it be at all possible to get this treated as a bug and fixed in 2.26, 
rather than treated as an improvement for a future version of DHIS2?  These 
rules were all working perfectly when we did intensive testing on our programs 
in 2.25 (eg they work properly in 2.25 da6a2df / 2017-02-02 06:43), so this 
limitation seems to have been recently introduced (very likely by accident, 
since other element names allow dashes), and it’s breaking configurations that 
have worked well up until now.

The reason we’re so keen on this is that Metrics for Management has published 
XMLs for 29 EquityTool programs, and these have now been downloaded and 
installed in a wide range of DHIS2 instances.   It will be a huge job to not 
only update the source names in all of these 29 programs and re-publish them, 
but also contact all existing users and ask them to reinstall the corrected 
programs.  If there’s any chance we could get the program rules in 2.26 working 
as they did before, this would save us an enormous amount of work…

Many thanks for any help you might be able to give us with this!

Regards, Sam.


From: Markus Bekken <mar...@dhis2.org>
Date: Wednesday, 19 April 2017 at 14:55
To: Sam Johnson <samuel.john...@qebo.co.uk>
Cc: DHIS2 Developers <dhis2-devs@lists.launchpad.net>, Kenzo Fry 
<kenzo.fry.consult...@gmail.com>
Subject: Re: [Dhis2-devs] Many program rules not firing in 2.26

Hey Sam!
Thanks for reporting.

I tested WHO RMNCH and 'Hide program stage' on Play, and found that it the 
problem is in fact what is indicated by the console message in point 4 below. 
The source field #{currentProganancyOutcome} did not exist. Seems someone has 
renamed it to
#{Current Progranancy Outcome} - see below to the left:
[id:7B8238F2-5B98-4966-B039-0DA99918253F]

Such a name change should ideally clean up the expressions using the source 
field, or at least flag the ones that has become illegal as a result of the 
name change. At the moment however you would have to manually update the 
expressions after a name change. Updated the expression now on Play, and the 
expression runs fine:
Expression with id rule:xOm49QX4Nsc was successfully run. Original condition 
was: #{current Progranancy Outcome}  != 'Live birth' - Evaluation ended up 
as:''  != 'Live birth' - Result of evaluation was:true
[id:6EF07903-D629-46AE-9D57-513472ADDDB7]

In general your rules hiding program stages should work fine, let me know if 
you find any other problems here.

Looking into the second part of the mail regarding Event Capture - this is a 
different problem: There is a dash in the source field name. Registered an 
improvement in Jira based on this: https://jira.dhis2.org/browse/DHIS2-1449 - 
but avoiding dashes is a possible workaround.

Best regards,
Markus

19. apr. 2017 kl. 12.43 skrev Sam Johnson 
<samuel.john...@qebo.co.uk<mailto:samuel.john...@qebo.co.uk>>:

Hi Devs,

I’m finding that a number of program rules aren’t firing in 2.26 – this is 
happening with both Event Capture and Tracker Capture.

This includes the sample ‘Hide Program Stage’ rule which has been added to the 
WHO RMNCH Tracker for the 2.26 release.  To reproduce in Play demo:
1.       add a new registration to the WHO RMNCH Tracker with date 2017-01-01
2.       complete the initial visit, and click ‘cancel’ to prevent creation of 
a second antenatal care visit
3.       click ‘+’ to create a ‘Care at birth’ event on 2017-02-01
4.       for WHOMCH pregnancy outcome, select ‘Stillbirth’, and complete the 
event.
The rule which should hide the postnatal program stage has not fired.  In the 
browser console, the following two errors are recorded are:
•         Expression #{currentProgranancyOutcome}  != 'Live birth' contains 
variable currentProgranancyOutcome - but this variable is not defined.
•         Expression with id rule:xOm49QX4Nsc could not be run. Original 
condition was: #{currentProgranancyOutcome}  != 'Live birth' - Evaluation ended 
up as:#{currentProgranancyOutcome}  != 'Live birth' - error 
message:SyntaxError: Invalid or unexpected token

The important error seems to be the second one, as in many cases this is 
appearing in isolation (without the first one), and is still breaking program 
rules.  For example, I’ve loaded the Cameroon EquityTool into the Play Demo 
instance, and any attempt to enter new Event Capture events for this program 
keeps generating similar error messages in the browser console, eg:
•         Expression with id rule:gXwzJFfRn5m could not be run. Original 
condition was: #{EQT-CM11Q06a} + #{EQT-CM11Q06b} >1 - Evaluation ended up 
as:#{EQT-CM11Q06a} + #{EQT-CM11Q06b} >1 - error message:SyntaxError: Invalid or 
unexpected token
These program rules have been extensively tested on earlier releases, and 
worked well – where users used to be prevented from entering invalid surveys, 
they can now save invalid surveys.

This is very serious, as it means that in 2.26, users can now bypass many 
program rules, and save incomplete or incorrect data.  But I’m also aware that 
there have recently been build issues with 2.25 and 2.26 releases – before I 
log a bug on Jira, could this be related to those build issues?

Regards, Sam.

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to     : 
dhis2-devs@lists.launchpad.net<mailto: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

Reply via email to