Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
Thanks for this great module.
Is it possible to extend the "conditional rules" section when editing a component setting ?
For now, you can only refer to 1 field. Is it possible to enhance this feature by adding the possibility to check multiple/unlimited conditional rules ?
Thanks.
Comment | File | Size | Author |
---|---|---|---|
#40 | webform_conditionals6.patch | 127.13 KB | quicksketch |
#39 | webform_conditionals6.patch | 122.69 KB | quicksketch |
#38 | webform_conditionals5.patch | 108.74 KB | quicksketch |
#37 | webform_conditionals4.patch | 108.71 KB | quicksketch |
#36 | 1215456-36-webform_conditionals-d7.patch | 119.19 KB | fenstrat |
Comments
Comment #1
quicksketchWhile it's *possible*, the code currently is designed for a single component to control the conditional logic. I think it's obvious that the UI regarding conditional logic needs some significant work, but I don't have any timeline for updating the system. Potentially we may move all conditional logic to a dedicated tab, rather than having it be part of the component configuration form. That might allow for a more verbose area for constructing complex AND/OR rules.
Comment #2
m-patate CreditAttribution: m-patate commentedThanks for your quick reply quicksketch !
I will wait this future awesome tab :)
Thanks a lot.
Comment #3
ccamp CreditAttribution: ccamp commentedBeing able to set multiple conditional rules for a field would be of great help. Any idea when this may be done?
Comment #4
quicksketchNot very soon. Consider funding a developer or attempting to develop it to help speed this along, right now there are hundreds of feature requests and many of them will get implemented before this one.
Comment #5
rbrownell+1
Comment #6
rbrownellI immagine a user interface similar to that of the Date module's ability to create a list of dates or CCK's multigroup would be ideal.
Comment #7
micheas CreditAttribution: micheas commentedYuck.
Unfortunately I have a project that sort of requires up to three OR conditionals for seven questions.
For my limited needs being able to add an additional conditional field would be good enough. (well as long as I can get the add button to work twice :) )
Would being able to press an "Add another condition" and having an additional conditional set appear be plausible?
(warning I have not looked at the code yet, although I have looked at the api, and that made me think that my needs shouldn't be two hard to meet, even if they aren't the best way to implement them.)
Do you have any recommendations for doing this? (I know, I know, it's open source, if I post a patch and you'll happily tell me what I did wrong )
Thanks in advance,
(depending on how ugly my attempt is I might assign it to myself in a few days.)
Comment #8
rbrownell@micheas
Perhaps an interface similar to that of the webform's element's (the page where you actually specify the components of the form) itself would be the best interface.
-R
Comment #9
quicksketchI'm working on this problem currently. Marking a few issues duplicate:
#1458826: Condition based on date field
#1513590: Webform multiple conditions
#1067266: Adding additional conditions like empty, not empty, ...
Comment #10
quicksketchHere's a screencast of the system in progress. Right now I have the UI working with all it's AJAX and JavaScript goodness, as well as conditionals saving and loading into/from the Webform nodes. It doesn't yet actually affect the display of components yet, provide an upgrade path, or work on same page components (all of which I'd like to get handled in this issue).
I'm marking this needs review for feedback on the UI, even though the code isn't ready yet.
http://screencast.com/t/JPNRkDy5R3A
Comment #11
David Stosik CreditAttribution: David Stosik commentedHello,
I'm in need of a similar feature, and actually started to work on it last week, so, instead of duplicating work, I would like to join forces and help getting this done. Is there a sandbox which would allow me to give it a try before giving my suggestions, and tell you what kind of help I can provide ?
Regards,
David
Comment #12
quicksketchWell I wouldn't recommend trying this out quite yet, since as I mentioned in #10, there are quite a few pieces missing. Besides just the "what doesn't work", I also need to work on the naming conventions (what's a "rule", a "conditional", "rule group", etc.), right now it's sort of all over the place. That said, I'm also about to have a very full week of unrelated client work, so I'm not sure I'll be able to make much progress for the next couple of days. If you'd like to take a stab at the incomplete parts I mentioned in #10, that might be a good place to start.
In any case, here's the patch of my progress thus far. It applies to the 6.x-3.x branch. I'm developing in D6 and then porting to D7 when it's finished so that I don't accidentally use a feature that only exists in D7. Considering the amount of AJAX functionality, it's good to figure out the work-arounds needed for D6 first and then remove the excess code in the port to D7.
Comment #13
quicksketchAh, that patch was missing the new webform.conditionals.inc file. Again with the new file added.
Comment #14
PieterDCJust watched your screencast. Nice progress!
Comment #15
jay_N CreditAttribution: jay_N commentedScreencast looks good - will definitely be available for testing this! I wrote similar code in the past to create a Webform 'feedback' screen (giving the user feedback on their responses for a particular submission) - might update that module with the conditional logic at some point.
Comment #16
fenstrat@quicksketch mentions this conditional work in the latest Modules Unraveled Podcast.
Splitting the conditions off into its own separate tab makes a lot of sense. That should also allow form_builder integration without much extra work right? What about rendering the hidden fields in form_builder, just show everything even if it is hidden?
@quicksketch your commitment to keeping the d6 and d7 branches in sync is impressive, just take a look at webform_ajax_callback() from #13.
I'll have time later this week to review this properly.
Comment #17
David Stosik CreditAttribution: David Stosik commentedQuicksketch, I just gave a try to your patch. Just so everyone know, if you get an error "corrupt patch", you only need to add a new line at the end of the file.
Must say the UI is great, and works smoothly, but I have some minor concerns :
I know there's already a lot of work to do to complete the "base" feature, but thinking of such use cases from now would, I think ease further development (I think that giving the opportunity to other modules declare their own rules operators or actions would be a way to get some interesting things).
Anyway, I'm looking forward to work on this !
I'll be waiting for your feedback,
David
Comment #18
David Stosik CreditAttribution: David Stosik commentedComment #19
quicksketchMaybe, I'd need to see the final result to see if this approach were any more clear. The easy-to-read sentence structure we have going on now makes for an easy to understand UI, even if the linking of the and/or fields is not what you'd expect at first.
I'm not entirely sure this is necessary. Can you think of a real-world example that needs AND/OR support? Since different rules can already be applied to the same field and they will be ANDed together, there's not anything that this approach would add. I specifically avoided this approach because of the additional complexity of the UI it would require.
While an obviously related task, I'm not sure I want to attempt an arbitrary condition/action system at this point.
Comment #20
quicksketchFollowup on my own comment above:
Upon further checking, I've found this isn't actually possible since you can't AND together a rule that says "hide component" with a rule that says "show component". The result of that operation is ambiguous and would lead to unpredictable results. In this current patch for example, the last triggered rule would win, which doesn't make a whole lot of sense. I suppose we could enforce these by order, but it's still not particularly useful. So implementing some kind of more complex AND/OR system might be valuable, but it would add additional complexity to this patch which has now gotten quite large (which is my own fault for merging requests).
This patch now:
- Conditionals save into the node and affect the form as you would expect, showing/hiding fields as needed.
- It also works with same-page conditionals. Hiding/showing components on the same page and even working with mixed conditionals from the same page and previous pages. This solves #732114: Merge Webform Conditional into Webform (support for same-page conditional fields).
- Partial form validation now makes it so that conditional fields that are omitted have their values removed. This both solves problems with skipping "required" fields that have been omitted and solves #680262: Conditional fields may save inapplicable values.
This whole patch is still written against Drupal 6. However the implementation is really quite ugly in places (see _webform_client_form_validate() for example), but I couldn't figure out a way to provide the same functionality without breaking our APIs. Considering the scope of this issue and the difficulty of maintaining APIs, I think we might consider branching Webform for a new major release (and leave Drupal 6 behind in the process). Considering #1001798: Rewrite token replacement system to use D7 tokens is also blocked on API breakage (or end-user breakage/functionality reduction) the time might be right for a new branch.
Comment #21
fenstratFantastic work quicksketch!
Would love to test this but we'd only be using this on D7. So huge +1 to splitting this off into webform-7.x-4.x
Comment #22
quicksketchLet's officially merge in a few other requests. Marked duplicate:
#680262: Conditional fields may save inapplicable values
#732114: Merge Webform Conditional into Webform (support for same-page conditional fields)
Comment #23
tedbow@quicksketch,
Tried to patch d6 but get this error:
UPDATE: OK fix "corrupt" error by adding new line at the end of the file
Comment #24
MustangGB CreditAttribution: MustangGB commented#9
Yay! quicksketch is teh awesomesauce (=
Comment #25
tedbow@quicksketch,
I am getting an error:
I am using PHP 5.3. The function should be "strcasecmp", right?
Comment #26
tedbow@quicksketch, btw forgot to say nice work!
Also I was thinking about the Conditional UI....
I was wondering if it would be useful to have multiple targets for a single rule after the "then"
So you could hide or show multiple components.
You could do this with the current UI but if you have many conditions you would have set the same group conditions in multiple groups.
Just a thought
Comment #27
quicksketchYes that's right. Sorry I was getting mixed up between stripos() and strcasecmp(). As you can tell there are a lot of conditional operators to check, so I'm glad you pointed that out.
Hm, true. Though of course you could use a fieldset (or page) to hide a group all at once.
Comment #28
tedbowYeah but I was thinking of cases where you might want to hide multiple fields(or fieldsets) that are in different places around the form based on the same conditions. So if the condition criteria change you would only have to change it in one place, instead of in multiple rules( and keep them the same).
On a different subject I was looking what kind of validation might be reasonable for "webform_conditionals_form"
I noticed I could set a rule that would allow a component to hide it self. Would there be use case for this or should that be prevented? I was thinking that maybe any component that is in the "source" list should not be able to be the "target"(or in the target list if you do the above change).
Another validation case: Should a component be able to hide a component that is on page previous to itself? To the end-user it would only have a noticeable effect if the user hit the previous page button. But also if I understand how your patch works the previous page's component's value would not be recorded in the submission if it was hidden by a component on a later page. I think this could be confusing to the user b/c they filled out the component would have no reason think that value would not be recorded(unless they went back to the page).
Comment #29
David Stosik CreditAttribution: David Stosik commentedHi,
I tried the patch too. That sounds great, but may I share some remarks ?
Wouldn't it be interesting to limit the rule hide/show to one instance per targeted field, using cascaded AND/OR conditions ? If global condition is verified, then show the field, if not, then hide it.
Finally, I know that a new branch must be considered as hard work, but do you have any idea of a possible roadmap ? Considering that I need this feature (among others) on my current project, I should be able to provide some help, may it be development, testing, or else.
Regards,
David
Comment #30
quicksketchThanks for the testing and reports.
That's certainly not supposed to happen. We short-cut the conditional checking if no conditionals exist. We may simply be returning the wrong value after short-cutting.
Yes that sounds like the intended behavior to me also. I haven't tested all the conditional combinations yet, so this should be a temporary problem.
There are several TODOs in the current patch. In the database at least, there is a column for "target_type" which is currently always "component", meaning that the target of the action will always be hiding/showing a component currently. We may extend it in the future, but the initial patch is just working on addressing the problems/shortcomings of the current conditional system.
Roadmap-wise, let's discuss that in #1561700: List of API-breaking Changes for a 7.x-4.x branch.
Comment #31
quicksketchHere's a new heavily revised patch that adds this functionality but targets the new 7.x-4.x branch. Changes:
- Tweaked the interface a bit to make fewer overall buttons and add some consistency.
- Fixed use of non-existent stricmp() function in comparisons.
- Fixed forms with no conditionals not showing any components.
- Ported to D7, which let us strip out a bunch of D6-workarounds.
- As part of the "cleaner" implementation that was not allowed without breaking APIs, the structure of the $submission->data array was changed for consistency. Instead of values for each component being in $submission->data[$cid]['value'], it's now just $submission->data[$cid]. The extra "value" nesting was a leftover from a backwards-compatible change. This allows us to interchange $submission->data and $form_state['values']['submitted'] easily, since we need to compare values during both validation and submission, when data is in different states.
So this patch is getting very large now, but I'm very pleased with the results thus far. I don't want to "destabilize" the new 4.x branch, but these changes seem to have defined effects and stick mostly to the conditional system.
I also tried a few new approaches to the "and/or" fields (which are currently linked to each other), but I couldn't get a solution that seemed to work better than what we've got right now. I tried unlinking them entirely, but found that more annoying and confusing than helpful (all use-cases I could think of were all ands or ors together anyway). Then I tried using text instead of select lists for all and/or display after the first conditional, but the UI inconsistency didn't look good either (attached a screenshot of this approach).
So right now the UI looks like this first screenshot. The second screenshot I tried to style as best I could but I found it inconsistent in appearance and confusing to work with.
Comment #32
quicksketchMinor update fixes a display issue with the conditional form for dates.
Comment #33
fenstratFantastic work Nate!
Comment #34
quicksketchThanks for reviewing @fenstrat!
I should have posted this yesterday. Even though it's not finished this version of the patch fixes a lot of problems:
- Fixes problems with checkboxes/radios not working.
- Adds new conditionals for "is blank" and "is not blank" to handle various situations before the user enters a value.
- Fixed behavior of invalid numbers and blanks in handling number fields.
- Started updating tests (this is the unfinished part). Still have a ways to go on this, but there are just so many combinations of conditions that we just have to test them properly.
Unfortunately this also undoes the whitespace fixes @fenstrat just did, since I don't know where those differences are.
Comment #35
tedbow@quicksketch, maintainer of Webform Conditionals here.
Just checking to see what this means for my module. So this is will go into 4.x, right? Will there be a 4.x for Drupal 6 or is 3.x the end for Drupal 6.
So if that is right that means that Webform Conditionals will only be needed Drupal 6(and anybody who doesn't upgrade Webform to 4.x on Drupal 7. Sound right?
Thanks again, these conditional changes are great!
Comment #36
fenstratAttached is an reroll of #34 with whitespace fixes (found with
git apply --verbose
).Radio/checkboxes are indeed fixed.
Marking needs review as more testing would be great (esspecially considering as there's mainly SimpleTest's remaining todo).
@tedbow this patch is for the 4.x branch only, and I'm pretty sure @quicksketch has said that the 4.x branch is Drupal 7.x only.
Comment #37
quicksketchThe last patch was missing the includes/webform.conditionals.inc file and accidentally included a test/conditionals.test file that didn't do anything. Be sure to apply to a clean 7.x-4.x installation.
Comment #38
quicksketchMerge of #36 and #37 together to incude the spacing fixes.
Comment #39
quicksketchUpdated patch with a few minor bugs fixed and made a few minor changes to the handling of dates and times. Biggest change is that we now have working tests that confirm over 200 combinations of same-page and multi-page conditionals, checking every single operator for every different kind of field in negative and positive matches.
We still have one big missing piece in that the upgrade path from the old conditional system to the new one needs to be written. Other than that I think this patch is good to go. More reviews are still appreciated.
Comment #40
quicksketchSame patch as #39, with an upgrade path from the old conditional system to the new one. Considering our old system was so limited, the upgrade task is not particularly complicated.
Comment #41
chertzogWhen i try and do a git apply to the latest 7.x-4.x i get a error
Seeing as that line correspondes to
Im assuming its a problem somewhere else.
Comment #42
quicksketchI've gotten that error also, I'm guessing Eclipse isn't properly generating the patch. However even then it still seems to apply and work fine. The error is at the very end of the patch every time.
Comment #43
fenstratYeah I had that same issue with your last few patches @quicksketch. Almost certainly related to a whitespace issue at the end of the file.
git apply
just wouldn't work. Howeverpatch -p1
does work.Also, solid work on those tests!
Comment #44
quicksketchTo make life easier for testers and help move forward the queue, I've committed and pushed this code into the 4.x branch. Yay!
Because this patch makes a pretty serious API change, I've started a handbook page akin to the D6-to-D7 upgrade page that provides Webform 3.x to 4.x instructions and changes: http://drupal.org/node/1609324
Comment #45
fenstratExcellent work @quicksketch!
Have you considered change notices to document then 3.x to 4.x updates? For example drush and zen have started using them.
Comment #46
quicksketch@fenstrat: I suppose that would be a good idea, but I can't figure out how change notices are supposed to work or how "normal people" find or use them. Seems like a good idea with a bad implementation.
Comment #47
fenstrat@quicksketch Fair point, however I guess it's developers who need to find and use them - not sure if they're "normal" or not! I actually find something like http://drupal.org/list-changes/zen quite useful. Anyway, I'm also fine with http://drupal.org/node/1609324
Comment #48
Upchuk CreditAttribution: Upchuk commentedHello,
I am having difficulties applying the patch as I am operating on a shared hosting environment.
Could someone maybe apply the patch onto the Webform module (for Drupal 6) and then post here the module with the patch applied so I can also install it?
Thanks a lot for your help!
D
Comment #49
quicksketch@Knob: This patch was never functionally complete for Drupal 6. While some of the earlier patches may apply to Drupal 6 (since that's what I wrote them against initially), none of the earlier patches will actually provide you with any working conditional logic. As I mentioned above, even if this patch were to be made to work with the Webform 3.x branch (for D6 or D7), it would likely break any existing theming and several contributed modules that depend on Webform. That's the reason why we branched for Webform 4.x, which won't have a D6 version.
Comment #51
Upchuk CreditAttribution: Upchuk commentedQuicksketch,
Thanks for the quick reply!
However, not a problem. I am working in parallel in drupal 7 as well on another server.
I am trying to figure out the best solution for a project for which webform is the core. For this, I need the multiple conditional patch applied to the webform.
I will try with webform-7.x-4.0-alpha2.tar.gz, i just saw you posted them here: http://drupal.org/node/1613588.
i believe this has the latest patch applied!
Thanks a lot!
D
Comment #52
Upchuk CreditAttribution: Upchuk commented@Quicksketch,
Does this have the latest conditional patch added to it? http://drupal.org/node/1613588
I installed it and seems to be working fine. There is big problem though that i encountered so far.
If I set a condtion and save - the condition works as I set it, but the page refreshes and comes back to the default condition (that is, with a select box, it puts the first option as the choice in the condition). Hence if i save again, the condition is lost. The result is that if i add a condition ,and then i want to add another one, I have to re-set the first one as well..As you can imagine, if you have 50 conditionals and you want to add a new one, it is not gonna work like this.
Are you familiar with this problem?
Thanks a lot!
D
Comment #53
fenstrat@Knob, yes webform-7.x-4.0-alpha2 has this conditional rules included, as mentioned prominently in the release notes.
For anyone interested in an overview of the new conditional system have a look at http://webform.com/blog/new-conditionals-system
Comment #54
quicksketch@Knob: Please open a new issue describing the problem from the beginning, as I can't reproduce a problem with the initial conditionals being lost. Perhaps try completely disabling, then uninstalling (under /admin/modules/uninstall) the module and then try again. As a "feature request" this issue is already finished.
Comment #55
quicksketchActually looks like someone already created an issue with an accurate description over here: #1619704: Conditions on a selection list field are reverted when editing.
Comment #57
quicksketchI included a set of tests that checks over 200 combinations of input fields and hiding/showing components; basically everything I could think of in terms of making sure things operate properly. SimpleTest can't currently check JavaScript though, so things like #1619704: Conditions on a selection list field are reverted when editing didn't show up in the automated testing. If you have specific ideas for more things that could be tested, let's open a new issue for that.
Comment #59
Upchuk CreditAttribution: Upchuk commented@Quicksketch
Did you manage to test it to put a condition of the following type:
If question 1 is either A OR B AND question 2 is either C OR D, then show questions 3
This is what I need and don't seem to find a solution since I supposed you have to have the condition for one question in on condition and you cannot break them apart into two.
Thanks
D
Comment #60
alex.skrypnyk@Knob
AFAIK, it is not possible to do this.
The solution for you would be to split these rules into all possible combinations. E.g.
Rule1
IF
Q1 is A
AND
Q2 is C
SHOW
Q3
Rule2
IF
Q1 is B
AND
Q2 is C
SHOW
Q3
Rule3
IF
Q1 is A
AND
Q2 is D
SHOW
Q3
Rule4
IF
Q1 is B
AND
Q2 is D
SHOW
Q3
But this is not the end yet. You would have to create rules to hide Q3 for inverse values.
I'm currently working on the module that will handle conditionals creations automatically.
Comment #61
VinceThePrince CreditAttribution: VinceThePrince commentedI have tested the new alpha release and it works fine.
But! I would love to see something like this:
Example Time!
Imagine I have an online repair service and I want to give customers a price estimate. (I am using webform currently to create this)
They can select a Device for example iPhone and the damage that the device has for example the Screen is broken.
I would be nice if you could say :
I hope this will be possible in the future, if I missed something or this is possible already. Please redirect me!
In addition, how can I upgrade my current version to the alpha version without losing my content.