multiple constraints

[MartijnR]

Avoiding multiple constraint attributes

[MartijnR]

This feature is really about being able to show different constraintMessages.

[pbowen-oc]

We have some ideas about how to accomplished the primary goal of this (showing distinct messages for distinct error conditions) without literally using multiple constraints. We are thinking that we may be able to show the additional messages (i.e., constraints 2+) via separate note items after the the primary input item, but we would want these to be tied to the query status on the primary input item. Let's discuss on our next call to see if this approach seems workable in general. I think it would at least avoid the performance concerns you had about supporting an arbitrary number of constraints per item.

On our end, I think we could handle the automatic creation of the additional note items based on custom columns in the XLS spreadsheet. For a complete solution, I think what we'd need is a way to mark these notes so that Enketo could identify them and act appropriately (i.e., as if a constraint is firing) when the user tries to Close, Complete, or Navigate on the form while one of these notes is currently relevant.

Basically, I'm thinking that we'd have the user define a second constraint using columns bind::oc:constraint2, bind::oc:constraint2_message, and (eventually) bind::oc:constraint2_type. We'd automatically convert that into a note item in the XForm that has Relevant = not(constraint2) and Label = constraint2_message. We'd need Enketo to consider that item being relevant as the same thing as a constraint firing on it's parent input item.

[MartijnR]

Another consideration is auto-closing queries.

It seems to be better to re-design the discrepancy note functionality by taking out the comment-status() checks from the form logic and built it into the dn functionality itself.

As a consequence the discrepancy note functionality will have to become more intelligent and start monitoring the state of the question it links to. Depending on how we implement multiple constraints, it may have to be linked to multiple questions (with bind::oc:for) and monitor all of them.

[MartijnR]

• [x] create XLSForm with multiple constraints in notes and a dn widget. Ignore autoqueries and comment-status() checks for now.
• [ ] then describe what needs to be added in terms of dn status changes
• [ ] then describe what needs to be added in terms of dn autoqueries
• [ ] based the previous 2 description create a new design for dn functioality

[MartijnR]

considering adding constraint to dn question and display constraint error in parent question

• consolidated dn history?
• UI - multiple icons?

[MartijnR]

Look into bind::oc:constraint2 etc (unlimited) with bind::oc:constraint2_message as it seems it might actually be easiest and fastest.

[MartijnR]

• [x] Is it possible to use a wildcard attribute template in enketo-xslt? - http://localhost:8085/transform/htmlform?xform=http://localhost:8081/oc-custom-multiple-constraints.xml&openclinica=true
• [x] If so, in enketo-xslt add oc:constraint and oc:constraint_message.
• [x] add tests for transformation
• [x] merge previous work in enketo-xslt into enketo-transformer
• [x] change to consisten class and attribute names in HTML transformation result, i.e. data-constraint1, invalid-contraint1, or-constraint-msg without prefixes.
• [x] do the same with oc:external, oc:required-type, oc:constraint-type by a blank oc:ATTRIBUTE support with consistent enketo attribute naming using data-oc prefix
• [x] fix: constraint message are also added as data attribute but shouldn't be
• [x] merge old branch in enketo-core and get all tests to pass
• [x] in stylesheet change .invalid-constraint selector to [class^="invalid-constraint"],[class*=" invalid-constraint"] (yuck!)
• [x] create question-invalid and question-error-message mixins in enketo-core to avoid future merge issues.
• [x] Change enketo-core to facilitate multiple constraints (as extension in fork). Make CONSTRAINT_CLASSES an overwriteable array?
• [x] change 'includeRelevantMsg' property to 'openclinica' in enketo-express-oc (2 places)
• [x] in enketo-core fix exception when selecting value in http://localhost:8005/?xform=relevant.repeat.test.xml with validateContinously set to true
• [x] change existing logic in enketo-express-oc for new attribute names data-oc-required-type and data-oc-external and data-oc-constraint-type
• [x] figure out how to change the strict validation feature with oc:constraint-type - can stay as is I believe as it only relates to regular constraints
• [x] refactor validationUpdate in enketo-core to facilitate extending it without too many future headaches
• [x] extend input.js getConstraint to return array of contraints in correct order (0 is default non-extended constraint)
• [x] create and publish a test form to run in enketo-express-oc => https://docs.google.com/spreadsheets/d/1Ws_Dgl_EjyDLa5f_xInOVAYp5Kt6LQAgbPRpSdEq6M0/edit?usp=sharing

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

• [x] extend FormModel.js validateConstraintAndType function to process contraintArray instead and return array (21) of results
• [x] extend Form.js setInvalid, updateValidatityInUi functions (and validationUpdate ?) to process result of validateInput with array of constraint results
• in OC fork, make sure to show matching message (fallback is default) - ~~ might be best to add default message for each constraint that doesn't have one in enketo-transformer.~~ -will be handled by validate https://github.com/enketo/enketo-validate/issues/74
• add some useful checks to enketo-validate or at least make forms pass if they do not currently, here is one already: https://github.com/enketo/enketo-transformer/issues/84, https://github.com/enketo/enketo-validate/issues/74
• [x] analog scale picker fixes: search for or-constraint-msg
• [ ] DN widget fixes
• [x] print style fixes for error messages shown/hidden
• [x] Grid theme error message, set order

Things to solve:

• [x] only show 1 constraint error message => CSS
• stop evaluating constraints if constraint fails (performance)

[MartijnR]

@pbowen-oc, I'm realizing it's quite important to figure out how this will (or may in the future) play with the strict validation of constraints. It would be great if strict validation only optionally applies to the master constraint (i.e. the "ODK constraint", if constraint-type is set to 'strict'), and that the additional "OC constraints" are all the same (i.e. all non-strict or all strict). Does that seem like it would work for OC?

[pbowen-oc]

@MartijnR - I'm not certain, but I suspect we would be fine limiting it to a single strict required and/or a single strict constraint per item with all other constraints on the item being non-strict. I don't think it would work if having a strict constrain for an item meant that all other constraints on that item had to also be strict.

[pbowen-oc]

We need to consider how this interacts with multiple queries. Ideally, we want there to be an association between a query thread and a constraint, but this may be extremely complex.

[pbowen-oc]

@MartijnR - Can you estimate how much effort it would take to implement each phase of what we had discussed earlier? a) multiple constraints (where any query suppresses all constraints) b) tie each constraint to a query thread, have each constraint only be suppressed by the query thread associated with it, have autoqueries added to the appropriate thread for a given constraint, and allow the user to add queries either to an ad hoc thread or a constraint thread (possibly via some way to select a constraint/ad hoc when adding a new query)

[MartijnR]

a) 40-80 hours b) I cannot estimate this with any reasonable accuracy, other than it will at least double the work of a.

[pbowen-oc]

We are ready to go ahead with the first part of this after Anonymous mode is implemented. As you work on it, please keep in mind that we will need it to be connected to our query thread model for our eventual release.

[pbowen-oc]

@MartijnR - It has been a long time since we discussed requirements for this. Let's discuss to make sure are on the same page regarding how multiple constraints would be evaluated and errors would be displayed.

[MartijnR]

• [x] only the regular constraint can be strict
• [x] show all constraint errors - ?? this conflicts with showing only first failed constraint
• [ ] individual constraint not linked to individual query thread (overall only)

[MartijnR]

http://localhost:8005/single/fs/i/MjMXeuoj?ecid=1 (Centro)

[MartijnR]

@pbowen-oc, I think this was asked and answered somewhere, but I cannot find it. Does a maximum of 20 additional constraints per question seem reasonable?

[pbowen-oc]

@MartijnR - Yes, I think that will handle all reasonable cases with ease. Most cases will likely only use a few extra constraints.

[MartijnR]

@pbowen-oc There is some conflicting info in my notes. I'm thinking you'd like to only show one constraint error at a time.

If so, we would evaluate constraint, oc:constraint1, oc:constraint2, ... etc in that order, until one of them fails and then show the error message corresponding to the failed constraint (with a fallback if message if missing).

Is this correct?

[pbowen-oc]

@MartijnR - I'm looking into it further, but I think we would want to see all messages so that the user knows all ways in which their input is invalid.My assumption is that we would similarly want autoqueries to be added for each failed constraint if the user closes the form without querying the item first.

Also, I'm thinking that this would tie in better to future desired behavior when we can associate each constraint with a query thread.

[MartijnR]

Ok, thanks. I'll await for confirmation. I think what you mentioned would actually be easier to implement.

[pbowen-oc]

@MartijnR - Confirmed, we would like to show messages for all failed constraints.

[MartijnR]

• [x] if item has a relevantError, don't show any other errors - check what is easiest to do, showing constraint error is also fine

I did't see any code that deals with this with default constraint, so I left as is for now Copied the same logic to remove custom constraints

[pbowen-oc]

We need to define the behavior when multiple constraints are active and 1) the user goes into the Query Widget to add a new query and 2) the user Closes the form and autoqueries are added.

[MartijnR]

This feature is now ready to be merged, tested and built-upon (for now it's in a separate branch). Known things todo are:

• any DN widget changes, probably best described in a new issue. Nothing has been changed wrt DN widgets
• Enketo Validate issues to help with form building, issues already created
• [x] possibly some analog scale issue

[MartijnR]

• [x] fix a failing test (relevant error)
• [ ] merge

[MartijnR]

• [x] perhaps better to not have Form.constraintNames in Enketo core, but keep constraintClassesInvalid and constraintAttributes

[pbowen-oc]

To do on OC end:

• [x] Determine what default query message is used when adding a new query if a constraint is firing (or more than one)
• [x] Determine what autoquery message is used when closing a form if a constraint is firing (or more than one)

[pbowen-oc]

• [x] For the default query message when adding a new query, if there are multiple error messages present for the item, can we concatenate them with " | " as the separator between them? We might also want to try a newline separator instead, but since we don't currently support that case for entering queries, we would need to test how that works for us.

• [x] For the autoquery when there are multiple error messages present we would want to use the same method to combine all current error messages. The existing prefix ("Automatic query for: ") should be added only once at the very beginning of the entry.

Another case that we thought of: If a strict constraint is firing (whether or not any non-strict constraints are firing), we would want the background for the item to be the orange strict error background. If there are no strict errors present but there are non-strict errors present, then the background should be the pink background for non-strict errors.

And one more question: Will participate be able to handle additional constraints all as strict constraints that don't allow the user to continue navigating forward?

[MartijnR]

Another case that we thought of: If a strict constraint is firing (whether or not any non-strict constraints are firing), we would want the background for the item to be the orange strict error background. If there are no strict errors present but there are non-strict errors present, then the background should be the pink background for non-strict errors.

created issue: https://github.com/OpenClinica/enketo-oc/issues/143

And one more question: Will participate be able to handle additional constraints all as strict constraints that don't allow the user to continue navigating forward?

Probably, with some complicated and difficult-to-maintain code changes. Please create a new issue if needed.

[pbowen-oc]

@pbowen-oc - Check if Participate automatically marks each constraint and required as strict. If it does and that is how the feature currently works there, consider only supporting one constraint in Participate.

[MartijnR]

• [ ] add tests to Enketo Core to try to ensure that the multiple-constraints-extension hooks remain there https://github.com/enketo/enketo-core/commit/78a971943c2e1b4d7c85c618a6522c8be538941e https://github.com/enketo/enketo-core/commit/fed550f0516e8c59a520d72a721865f04cf52cf2

[MartijnR]

@pbowen-oc: are multiple constraints still a desired feature? If not, it will save time to remove the custom code instead of moving it to enketo-core.

[MartijnR]

FYI, I believe this is the test form I was using: https://docs.google.com/spreadsheets/d/1Ws_Dgl_EjyDLa5f_xInOVAYp5Kt6LQAgbPRpSdEq6M0/edit?usp=sharing