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

Add a new feature that allows designating a field as a required sub-property. #1191

Open
yancao77 opened this issue Jun 27, 2023 · 1 comment
Labels

Comments

@yancao77
Copy link

Is it possible to add a new feature that enables the designation of a field "F" as a required sub-property within the element "E" (0-N)? This would imply that if there is an instance of "E", the "F" field must be filled. However, if there is no instance, it can remain empty.

@graybeal
Copy link
Member

I believe that to get what you want, a restatement may make it more precise. As I understand the desire, the F field must be filled if and only if E, the element within which F appears, has some meaningful values. (You can only tell if "there is an instance of E" if some field within E has content. Elements themselves don't have filled-out values, only their fields do.) So then the question becomes, for each element, how to know if it has meaningful content.

So I can think of 4 use cases that might be useful to satisfy:

  1. If some other field G of element E is filled, then F must also be filled. (This rule would also hold for any 'iteration of E', where E is MULTIPLE=Yes—then field G of iteration i of element E being filled means field F of iteration i of element E must be filled.
  2. If any non-F field of element E is filled, field F must also be filled. (Also holds for iterations of E.)
  3. If some field external to element E is filled, field F inside element E must also be filled (for all iterations of E).
  4. Instead of 'the field is filled' in 1 thru 3 above, the constraint could be 'the field passes some test', like value > 30, value="Test", or number of values > 1.
  5. Boolean combinations and negations of the above. (Ick.)

I laid it out this way because I suspect this is a variant or analog of skip logic, also discussed in

In the skip logic case, the question is whether a field should be displayed. In this case, the question is whether a field should be required. Both require display-time evaluation of some value or values in an arbitrary computation; this case also requires validation-time execution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants