Anro
April 24, 2024, 10:49am
1
We’ve recently been asked to restrict household heads to above 9 years old. This prompted us to constrain the appropriate select-contact search field as such.
We found that loading a old record, where a < 9 year old household head was saved, causes the first page of the form to be inaccessible.
The first screen of the form normally:
The second screen of the form normally:
Editing the “member test” date_of_birth in the db to an age that fails our constraint results in the following page being shown first:
Notice that there’s no previous button.
The affected form can be found here .
Well here we are again…
Logged a bug for this. Constraint violations are not properly handled when loading contact data on a separate page…
opened 06:58PM - 24 Apr 24 UTC
Type: Bug
Enketo
Affects: 4.0.0
Affects: 4.1.0
Affects: 4.1.1
Affects: 4.2.0
Affects: 4.0.1
Affects: 4.1.2
Affects: 4.2.1
Affects: 4.2.2
Affects: 4.3.0
Affects: 4.4.0
Affects: 4.2.4
Affects: 4.3.2
Affects: 4.4.1
Affects: 4.2.3
Affects: 4.3.1
Affects: 4.5.0
Affects: 4.5.1
Affects: 4.4.2
Affects: 4.5.2
Affects: 4.6.0
**Describe the bug**
Because of https://github.com/enketo/enketo/issues/62 we e… nded up adding [this logic](https://github.com/medic/cht-core/commit/2a25f877e0a0d8b37d9387fd294943ed6549d2a9#diff-4a2c03281e8e8de1af756938426de0e78d0529cfddf02998fc13754805c113daR92) 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**
1. Create a multi-page form that includes the following _on the second page_ so that it references a valid contact accessible to the user:
| type | name | appearance | constraint | default |
|----------|--------|----------------|------------------------------------|---------------------|
| string | _id | select-contact | ../name = “This is the wrong name” | *valid_contact_uuid |
| string | name | | | |
2. Open the form
3. See that the first page of the form is skipped and it jumps right to the second page where the constraint violation error is displayed.
1. Also see that the "Previous" button is not displayed.
**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](https://forum.communityhealthtoolkit.org/t/constraining-a-select-contact-causes-1st-form-page-to-be-completely-inaccessible/3464).
I have confirmed this functionality worked as expected on `3.17.2`.
The only workaround I have found for this is to move your contact selector to the first page. If you did that, I think everything would function as expected even if the constraint gets violated.
1 Like
Once again, thank you so much for the detailed report and recreation steps! This was a tricky one to pin down and it was very helpful to be able to reference your form!
1 Like
