In page 1 of my multi-page webform, I have a component called COUNTRY with default_value = %get['country']
In page 2, I have a fieldset called ALL_OPTIONS, without any conditional rule applied to it.
Inside ALL_OPTIONS, there are 2 fieldsets: one of them is FOR_SPAIN, the second is FOR_USA
Obviously, the first one has a conditional rule: Field COUNTRY is one of "Spain".
You can easily guess that the fieldset called FOR_USA has a conditional rule: Field COUNTRY is one of "United States".
Well, they both display always, no matter the value of field COUNTRY.
But if I move those 2 fieldsets outside the parent ALL_OPTIONS, they seem to follow the rules.
And that's the bug.
Cheers,
Alex
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | webform_recursive_conditionals.patch | 3.68 KB | quicksketch |
| #2 | webform_recursive_conditionals.patch | 3.17 KB | quicksketch |
Comments
Comment #1
quicksketchThanks, I've confirmed this bug. It doesn't look trivial to fix unfortunately, and it almost certainly means passing in more parameters to _webform_client_form_add_component(), which is already swamped with parameters. Here's a take at attempting to fix this problem. It does correct the display of conditional elements when they're within fieldsets, but it doesn't seem to work when viewing a submission or getting an e-mail containing a submission. In those situations, the e-mail contains all nested elements, even if they should be excluded.
Comment #2
quicksketchPatch so far, which fixes the rendering of forms but not submission viewing or e-mails.
Comment #3
quicksketchOkay I found the problem with e-mails and viewing was because these display modes always are a single page, and so $page_num is always 0 for these displays. One more check to the rules and things started working properly. I'm not thrilled with the excessive number of arguments to _webform_client_form_add_component(), but I don't see a way to correct this without rearchitecting the conditional logic. So for now, additional parameters it is.