Form broken when contact loaded by Contact Selector on different page violates constraint #9063
Labels
Affects: 4.0.0
Affects: 4.0.1
Affects: 4.1.0
Affects: 4.1.1
Affects: 4.1.2
Affects: 4.2.0
Affects: 4.2.1
Affects: 4.2.2
Affects: 4.2.3
Affects: 4.2.4
Affects: 4.3.0
Affects: 4.3.1
Affects: 4.3.2
Affects: 4.4.0
Affects: 4.4.1
Affects: 4.4.2
Affects: 4.5.0
Affects: 4.5.1
Affects: 4.5.2
Affects: 4.6.0
Affects: 4.7.0
Affects: 4.8.0
Enketo
Affects Enketo forms
Regression
Affects a feature that worked in a previous release
Type: Bug
Fix something that isn't working as intended
Describe the bug
Because of enketo/enketo#62 we ended up adding this logic to automatically trigger
Form.validateContent
on the Enekto form when the db-object-widget finishes loading contact data into the form. The goal was to clear out any existing constraint violations that were resolved by loading the contact's data.Unfortunately, this approach did not account for what happens if the contact data being loaded is not on the current page and a constraint violation is created by the loaded contact data. In that case, Enketo will try to jump to the question with the constraint violation, even though it is on a different page. Besides jumping around in the form, this also breaks our paging logic for the Next/Previous buttons so these may not be displayed/function properly.
To Reproduce
Expected behavior
Ultimately, we want to avoid jumping around in the form when there is a constraint violation on a different page. (Or maybe, more precisely, we should never jump forwards, but could jump backwards if needed. Regardless, if we jump we need to make sure it does not break the Previous/Next/Submit buttons...) Honestly, though, fixing the Enekto issue at its source may be the cleanest way to proceed here....
The only workaround I have identified here is to design your forms such that if you have constraints based on data loaded by a Contact Selector, make sure the contact is loaded on the user's current page in the form and not on some other page. This is how things work normally when the user actually searches for a patient to load (they are already on the same page as the selector). But it is possible to trigger a contact selector on a different page via
calculation
expressions and/or just pre-loading the contact data when the form is initialized (like my example above). In the case of contact data loaded on form init, the contact selector needs to be on the first page. If it is on the first page, then the constraint violation is still triggered, but once the user addresses the issue, they can proceed with the form since the Next/Previous buttons are not broken (and they have not missed any pages of questions).Additional context
Originally reported on the forum.
I have confirmed this functionality worked as expected on
3.17.2
.The text was updated successfully, but these errors were encountered: