The spec says "Actions triggered by odk-new-repeat must be nested in the repeat form control." We only enforce this when odk-new-repeat is the only triggering event but there can be more than one.
In XFormParser, there's if (actionHandlers.containsKey(name) && child.getAttributeValue(null, EVENT_ATTR).equals(Actions.EVENT_ODK_NEW_REPEAT)) which is only true for actions triggered only by odk-new-repeat. It's common to have both the odk-instance-first-load and odk-new-repeat events triggering actions.
pyxform has been generating forms with actions in the model triggered by both events. This seems to mostly work in Collect, as long as there's only one repeat defined. If a form has more than one repeat, Validate complains and Collect crashes.
If we were to change the test to e.g. child.getAttributeValue(null, EVENT_ATTR).contains(Actions.EVENT_ODK_NEW_REPEAT), we'd be following the spec. But existing forms converted with pyxform would start crashing in newer versions of Collect.
The spec says "Actions triggered by odk-new-repeat must be nested in the repeat form control." We only enforce this when
odk-new-repeatis the only triggering event but there can be more than one.In
XFormParser, there'sif (actionHandlers.containsKey(name) && child.getAttributeValue(null, EVENT_ATTR).equals(Actions.EVENT_ODK_NEW_REPEAT))which is only true for actions triggered only byodk-new-repeat. It's common to have both theodk-instance-first-loadandodk-new-repeatevents triggering actions.pyxformhas been generating forms with actions in the model triggered by both events. This seems to mostly work in Collect, as long as there's only one repeat defined. If a form has more than one repeat, Validate complains and Collect crashes.If we were to change the test to e.g.
child.getAttributeValue(null, EVENT_ATTR).contains(Actions.EVENT_ODK_NEW_REPEAT), we'd be following the spec. But existing forms converted withpyxformwould start crashing in newer versions of Collect.