Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Form broken when contact loaded by Contact Selector on different page violates constraint #9063

Open
jkuester opened this issue Apr 24, 2024 · 0 comments

Comments

@jkuester
Copy link
Contributor

jkuester commented Apr 24, 2024

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

  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
  1. Open the form
  2. 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.
  3. 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.

I have confirmed this functionality worked as expected on 3.17.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment