In this effort we are replacing a flag that is set in the program stage metadata called “Complete only if validation passes”. We are replacing the flag with a three-coice list that you can read about in the Jira if you are interested.
We have a question for the community on one of the designed validation strategies:
Does anyone know a use case where we need the validation strategy that is called “NONE”? This validation strategy would mean that required fields are never validated, not even when the user completes the event. It would seem that in these kinds of use cases you would be able to not assign any required fields at all, in stead of using the validation strategy of “NONE”. The reason “NONE” was added to the design in the first place was that it would be the equivalent to not checking the flag called “Complete only if validation passes”.
If we do not have any use cases for the “NONE” validation strategy, we want to take it away and effectively remove the old flag of “Complete only if validation passes”. Assuming you always would want to validate required fields on complete as a minimum.
Thanks for the opportunity to comment. It sounds like the Aggregate and Events/Tracker sides of DHIS2 might be using slightly different terminology and concepts here, and it would be great if they could be aligned.
My understanding is that on the aggregate side, there are two completely different concepts:
‘Validation’, which means validation rules must successfully run.
‘Compulsory fields’, which means a field must be completed.
These are very distinct concepts - there are separate configuration tick-boxes in Data Sets for ‘Complete allowed only if validation passes’ and ‘Complete allowed only if compulsory fields are filled in’. The first ‘validation’ check doesn’t care whether or not a field is mandatory - so the concept of ‘validation’ doesn’t include compulsory fields.
From what you’ve outlined in Jira, it sounds like you’re proposing that ‘validation’ in Tracker will be used to describe the enforcement of ‘compulsory’ data elements and TET attributes, rather than the enforcement of program validation rules. (I realise that the latter don’t need a tick-box, as the ‘warning’ vs ‘error’ Actions determine whether or not it blocks the event from being ‘completed’.)
In order to maintain consistency between Aggregate and Tracker, would it perhaps be possible to align the terminology between these two, so that ‘validation’ refers strictly to ‘rules’? This would involve renaming this new setting in line with the Aggregate side of things - eg something like “Enforce compulsory fields”, with options “Never”, “When saved” and “If completed”; with the “When saved” option not available for Tracker programs. (I know this sounds pedantic, but I’ve found that during training, conflicting terminology in different parts of DHIS2 can really confuse new users.)
I can’t actually think of the need for a “Never” option (since this would be a denormalisation of the ‘compulsory’ setting for each program stage data element) - in which case this two-option setting would only be required for Event Capture programs, right? But others might be able to suggest good reasons to keep a “Never” option.