[Feature request] Tiered conditionality for form fields.

[AucklandIO]

Is your feature request related to a problem? Please describe.

Right now, conditional fields are based on a single condition. This causes issues with nested conditions, whereby fields who's conditions were previously met and which have been displayed do not have their conditions updated when those nested conditions are no longer met.

Here is an example: https://github.com/user-attachments/assets/da57aa45-0e38-4210-bd66-826ba2534611

1. Domain is the top level Field with the values of "Personal" and "Professional".
2. Personal Areas is conditional on Domain: Personal
3. Professional Areas is conditional on Domain: Professional
4. The video demonstrates a further nested condition. Personal/Areas/Interests, which has two select Options: Interest 1, and Interest 2.
5. When the Domain is subsequently changed to Professional while the Personal Area (Interest) is selected, the field for Interest remains selected, despite one of its parent conditions no longer being met (Domain: Personal would be the first condition in this chain, and so subsequent conditionals should become invalid.

Describe the solution you'd like

To solve this issue, I would like the ability to add arbitrary levels of conditions to for any given field, and in this way manage all conditional requirements needed to avoid these invalid fields being present.

Alternatively, all conditionals could check for nested conditions further down the chain, and mark them as "unmet" when a parent condition is no longer valid.

I think ultimately both of these options would serve the plugin immensely.

[AucklandIO]

In addition, dependent child fields that were previously selected and set, and then had parent fields modified, and subsequent child fields set are maintained, erroneously. In the following example:

Domain is set to Personal Personal Area is set to Interest An interest is chosen: Interest 2 The domain is set to Professional, yet The interests field remains, and Interest 2 remains assigned (despite it being a child of Personal Domain/Interests Area) The Domain is set back to Personal The Personal Area is set to Health The Domain is set to Professional The Professional Area is Set to Writing The Writing Type is set to blog post The form is submitted.

The Form Results of this submission are: Domain: Professional (Correctly set) Professional Areas: Writing (Correct set) Personal Areas: Health (Correctly set, but should be absent from the form result as Domain is Professional) Interest: Interest 2 (Correctly Set, but Interest should be absent as it is a child field of "Personal Areas", and "Personal Areas" is a child of the "Personal Domain", which is no longer present. Writing Type: Blog post (Correctly Set)

https://github.com/user-attachments/assets/f1c838ef-8f17-43b7-b6ff-7f70a4b3e7fd

I hope this clarifies the behavior I am attempting to describe, and a path forward for correcting the issue, and implementing the child dependencies / adding arbitrary number of conditions to the Field Conditionality feature of Modal Plugins.

[AucklandIO]

I have noted now that Naming the Fields the same Name, and Labelling them separately does overcome one of the issues with regards to tiered conditionality. Now when the Fields are named the same, they will overwrite the preview level of fields set based on that conditionality. For example:

https://github.com/user-attachments/assets/4b17dffa-7c9b-498b-9c00-db5eb908cdd8

It seems that Fields will be overwritten by conditionally dependent fields when they are the same label, which is expected behavior. But subsequent child dependencies are not cleared and removed, which would also be expected behavior.

Since my use case would employ different names for child fields, this would be I will always assign unnecessary frontmatter properties to files if I was indecisive when using the form to create them.

I think this can be overcome by simply clearing child fields from the proposed form composition when their parents are no longer present.

[seomwan]

It seems that Fields will be overwritten by conditionally dependent fields when they are the same label, which is expected behavior.

That's a neat trick!

[AucklandIO]

It seems that Fields will be overwritten by conditionally dependent fields when they are the same label, which is expected behavior.

That's a neat trick!

I'm sorry, I got that backwards!

Labels are independent, but if the fields have the same NAME they will overwrite one another. So you can have two of the same named fields, with different LABELS and make them conditionally dependant on higher, separate fields, and overwrite them based on different conditions.

[danielo515]

I added this feature with the most possible basic feature set, and left everything else to be based on feedback (check here for reasoning). This was something I was not sure about. To me, it feels natural that, if a field that you depend on are not rendered, yours is not either, but I was not sure about it, so I decided to just leave it as is. I would like to collect more user feedback before I take a decission, but if nobody else chimes in, I think I will do what I consider most obvious.

This may feel natural, or logical, but please understand that such things vary a lot from person to person, and what one considers logical it is unexpected for others. A great example is your "abuse" of field names. I consider to have several fields with the same name a bug, but it was never an issue until this feature came out. Now, you found it and are taking advantage of it 😂 . What will happen if I now fix that bug? I will be breaking your workflow. This is just a demonstration of how every new feature or every bug fix may break the workflow of someone.

[AucklandIO]

I added this feature with the most possible basic feature set, and left everything else to be based on feedback (check here for reasoning). This was something I was not sure about. To me, it feels natural that, if a field that you depend on are not rendered, yours is not either, but I was not sure about it, so I decided to just leave it as is. I would like to collect more user feedback before I take a decission, but if nobody else chimes in, I think I will do what I consider most obvious.

This may feel natural, or logical, but please understand that such things vary a lot from person to person, and what one considers logical it is unexpected for others. A great example is your "abuse" of field names. I consider to have several fields with the same name a bug, but it was never an issue until this feature came out. Now, you found it and are taking advantage of it 😂 . What will happen if I now fix that bug? I will be breaking your workflow. This is just a demonstration of how every new feature or every bug fix may break the workflow of someone.

Haha, well that's why I framed it as a feature request, not a bug report! I think conditionality expansion would add a huge "language" for users when developing the forms. I have since considered requesting even more of this kind of expansion. My specific "abuse" of field names (love that by the way) is just a work around I discovered while I was trying to find a solution for my intended use. I am by no means married to the idea and I think that the tiered conditionality would solve this issue and bring tons of functionality to the plugin.

I do consider this "Missing dependant conditional fields included in submission" omission a bug, and would love to see it expanded upon in the future. I just think it's natural to have levels of conditions, but I am not sure if I explained the issue I am having with it well enough. Right now, the nested conditions remain if they are too deep in the hierarchy tree. Like this:

Grandparent condition: Enabled, present in the form, present in the submission Parent field based on Grandparent Condition: Enabled, present in the form, present in the submission Child field based on Parent Condition: Enabled, present in the form, present in the submission

I enter some information into the child field, but Oh No! I have decided not to include them this time.

now I disable the grandparent field

Grandparent Field: disabled, not present in the form Parent field based on Grandparent Condition: disabled, absent from the form, but still present in the submission Child field based on Parent Condition: disabled, absent from the form, but still present in the submission

If I disable the Grandparent condition, the form will still include any information provided in the parent and child fields while they were present in the form. They are certainly removed from the form while I'm working on it, but the submission preview shows that the information captured in them while they were available is still included in the file. They shouldn't be included in the submission if they aren't present when the form is submitted.

I would love to have a call with you and share my screen to demonstrate if you are open to arranging a meeting where we could discuss my notes.

The Modal Forms plugin is honestly the most important plugin to my quick capture workflow and would love to discuss it further. I apologize for inundating you with feature requests.

[danielo515]

indeed the idea is, if I make this "cascading conditions" to also make the values not visible not appear in the result. As I said, I started this as a very minimal, because it was not a feature I was needing that much (although, I admit I had a little desire for it) so I decided to not do a drastic change. Specially because, if anything went wrong, it will be harder to know what part of the new very complex feature it was.

That said, it's very hard for me to imagine a scenario where you want hidden fields to appear in the result, so omitting them seems like the sensible thing to do to me