Change in d2:validatePattern evaluation: please review your program rules

Hi everyone,
We want to make you aware of a change that may affect existing program rules using d2:validatePattern.

What changed
The way d2:validatePattern handles escaping in regular expressions was fixed (DHIS2-21359). The fix is included in:

  • Android Capture app 3.4.2 and later, through an update of the expression parser
  • DHIS2 server patch versions 2.41.9, 2.42.6, 2.43.2 and 2.44

The change is intended and makes evaluation correct and consistent. However, some patterns that worked before may now evaluate differently. This is most likely for patterns that relied on the previous escaping behavior, such as sequences with backslashes like \\b.

The documentation has been updated to reflect this change and explain how it may affect existing program rules.

What you might notice
Rules that used to trigger no longer do, or the other way round. For example, a field that should be shown after selecting an option stays hidden.

How to find affected rules
You can list program rules whose condition uses the function with this API call:

/api/programRules?filter=condition:like:validatePattern&fields=id,name,condition,program[name]&paging=false

Program rule actions can also use it, for example in ASSIGN expressions:

/api/programRuleActions?filter=data:like:validatePattern&fields=id,data,programRule[name]&paging=false

If possible, consider reviewing patterns that rely on escaping and simplifying them where appropriate. For example, a pattern such as \\d{6}\/\\d{2} could potentially be rewritten as [0-9]{6}/[0-9]{2}, avoiding backslashes while preserving the intended matching behavior.

We did notice this but, as you have noted, have removed the backslash format and transitioned all regex to the [0-9]{2} style, which has normalized the experience across old and new versions. Thanks for the update and context!