OC only: new Participate view

[MartijnR]

non-readonly, and non-review(dn)-only view:

• constraint, required are hard checks, which means the value should not be stored in the model until they pass
• (dn will not be required)
• 1 button that closes the form on last page (Close probably), without auto-query, but all errors have to be corrected by the user. No auto-queries even if the user closes browser and there are errors (due to dependencies - existing valid value becomes invalid)
• remove goto-start and goto-end buttons (and no ToC)
• block navigation when errors on page
• for hard constraints show constraint message in modal (because value is cleared) unless it was valid before in which case it will show as a regular constraint error

these "hard checks" may in the future be combined with regular checks

[MartijnR]

This issue replaces #944.

Possible implementation issue:

some widgets may fire change events when a user is trying to enter a correct value using e.g. keyboard arrows, slider on touchscreens. The change event that sets the value to '' would prevent the user from correcting the value.

[MartijnR]

• [x] create POST /survey/collect/p4 and /instance/edit/p4 API endpoints
• [x] add API tests
• [x] complete API documentation
• [x] create views (dedicated?) with new encrypted id
• [x] figure out descriptive name of endpoint/view ("participate"?, "participate4") and change code => PARTICIPANT
• [x] in enketo-xslt and transformer, let new attributes pass into HTML result
• [x] add logic for hard constraint and hard required to engine - THEY SHOULD COME BEFORE THE EVALUATION CASCADE AS WE TRY TO PREVENT CHANGES TO THE MODEL. MAY BE BEST DONE WITH CHANGE EVENT HANDLER
• [x] is dedicated main js entry point necessary or can we use main-fieldsubmission?
• [x] In order to evaluate an expression the value has to first be stored in the model! This is a problem because it would immediately trigger a fieldsubmission, before it is reset. And somehow we need to have a record of the previous value as well. One option would be to clone the model, set the value, perform the evaluation and either let it propagate or set the view back to the previous value. This is pretty heavy handed though.
• [x] we need to check constraint synchronously in order to prevent propagation (when necessary).
• [x] make "validate page" a hardcoded setting for this particular view? ONLY PREVENT NAVIGATION FROM STRICT REQUIRED AND CONSTRAINT
• [x] prevent Back navigation too? - probably not
• [x] should ecid, pid, jini, go_to_error_url be included in this view? - remove pid and jini for now
• [x] Close button logic (deviating from closeSimple or same?)
• [x] override validatePage setting in participant views
• [x] create alternative validateContent function that looks at strict logic only
• [x] override validation function used in page next/prev handler
• [x] a pragmatic solution would be to validate both soft and hard constraints, but only block page.next if .invalid-constraint [oc-constraint-type="strict"], .invalid-required [oc-required-type="strict"] are found!
• [x] merge + propagate changes in enketo-xslt and enketo-transformer via enketo-core, enketo-express

[MartijnR]

@pbowen-oc I've confused myself wrt to "hard required" (apart from the logic when clicking Close). In this scenario, what is the desired behavior of hard required:

Question A is hard required and currently has a value "a". The user clears the value.

[pbowen-oc]

@MartijnR - I think the value should be cleared and submitted back as null in that case, but the required error message should then be displayed right after (basically, I think this is how it works for required items in general now). Other hard required functionality, like blocking moving to the next page and blocking clicking the Close button, should also be in effect as soon as the error appears.

I need to consider this more and talk about it internally. The more I think about it, the more confused I am. I will get back to you about this.

Regarding hard constraints, if the item has value 5 and the user enters value 11 (which violates the constraint condition), the item will immediately revert to the previous value (5), not null, correct?

[MartijnR]

constraint	bind::oc:constraint-type	required	bind::oc:required-type
. > 5	strict	yes	strict

(any other value for constraint-type would be ignored)

test form: https://docs.google.com/spreadsheets/d/13prx-MFfcauAmjp5VxjdnRCLNtHK1BEF4xZ1o9Mtf8M/edit?usp=sharing

[MartijnR]

local test form: http://localhost:8005/single/fs/participant/i/::9fab8d28abfc8e0ee51b3744d21963fa?ecid=a

[pbowen-oc]

@MartijnR - We've thought about it more and decided that attempting to clear a strict required item should work in a similar way to attempting to change the value of a strict constraint item to an invalid value.

If an item is strict required and currently has a value and then the user clears the value of that item, it should immediately revert the item to its previous value (without submitting the blank value to OC) and show a popup error message on the form.

If a strict required item is blank on the page, the user should not be able to change pages. If a strict required item is blank anywhere on the form, the user should not be able to use Close/Complete.

[MartijnR]

@pbowen-oc in the common page validation feature, Enketo only requires validation for Next, not for Back. Would you want this custom hard page validation to do the same or block both Next and Back if current page fails hard validation?

[pbowen-oc]

@MartijnR - Yes, we should only block advancing to the next page, not going back to the previous page. If the Go to beginning/end buttons are present, it should similarly prevent going to the end but not going back to the beginning.

[MartijnR]

This work is available for initial testing in develop branch.

[MartijnR]

• [x] Close button should only be on last page
• [ ] Ignore strict validation for Close button if no fieldsubmissions were made at all. TBC

[enketo-issue-mover]

This issue was moved to OpenClinica/enketo-express-oc#48