Dynamic Default values are not reflected in the Query Widget History

[pbowen-oc]

Initially added as a comment for OpenClinica/enketo-express-oc#419

Preview mode Steps:

1. Open the attached form in preview mode - dynamicdefaulthistory.xml.txt

2. Note that the dynamic defaults are populated for all items as expected

3. Click the Query Widget for one of the items

Expected: The item value change from null to the default will be listed.

Actual: There is no history.

Field submission mode Steps:

1. Open the same attached form in edit mode
2. Note that the dynamic defaults are populated for all items as expected
3. Click the Query Widget for one of the items in the repeating group

Expected: The item value change from null to the default will be listed.

Actual: There is no history.

Note that in edit mode, the items not in the repeating group do show the history as expected.

[MartijnR]

http://localhost:8005/single/fs/i/2nmkflnC?ecid=1

The issue is that the previous value (any static defaults) cannot be determined by the widget.

The reason this works for some questions atm, is because in the past OC did not use defaults and the initial value was therefore considered to always be empty.

• [ ] figure out how to properly determine the initial model value in dn widget - are the events prevented from firing if the value is not changed? XFormsValueChange ✅ , InputUpdate (❌ needs work in input.clear), FakeInputUpdate (❌ same as inputUpdate)
• [ ] let input.setVal return a boolean to indicate whether value was changed and let input.clear only fire events when changed

Looks like the elements inside repeats no longer exist by the time the fakeInputUpdate events are fired

This is one of the key issues, and a fundamental flaw in the repeats module. The odk-instance-first-load event fires before the repeats are initialized.

• [ ] during initialization of repeats, could repeat view not be removed? - issue with (at least) repeat numbering, and probably also with datalists (autocomplete widget)
• [x] why is the inputUpdate event during odk-new-repeat not detected by dn widget? - input update event fires BEFORE dn widget initializes in new repeat! - potential fix in enketo-core uncommited

There is also an issue with repeats that get a second event that sets the value back to ""....

* [ ] figure out why that second event is fired (maybe clearing values in template?)

[MartijnR]

This requires a very thorough overhaul of the repeat module in Enketo Core. It is not pragmatic to do this since OC is using a branch of Enketo Core.

The issue is not with the core functionality but only with generating audits (which OC doesn't store, but regenerates on the server).

Implementation notes (to self):

It requires not removing the first repeat view (unless necessary for jr:count). However the current implementation is lean and robust because we remove the first repeat view. The numbering/datalist/radiobutton processing could be done in a separate function that could be called for the (unremoved) first repeat view instance. However, a lot tests fail when doing this, because of forms that do not have a first model repeat instance.

[MartijnR]

To investigate: Perhaps the whole audit feature should be rewritten and be directly linked with fieldsubmissions that are sent.

1. when fieldsubmission is generated, find form control that matches it (if it still exists, but I think there are no audits for deleted nodes)
2. send a new custom event to the form control that the DN listens for

[pbowen-oc]

@MartijnR - Given your comments above about the complexity and since the lack of in-session auditing in this case is compensated for by OC, I think this might be good to leave until after our next release.

[pbowen-oc]

The revised approach sounds like a good fit for our model. I think we should do this following our next release. We'll note the current behavior as a known issue in the meantime.