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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

While 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.

m-patate’s picture

Thanks for your quick reply quicksketch !
I will wait this future awesome tab :)
Thanks a lot.

ccamp’s picture

Being able to set multiple conditional rules for a field would be of great help. Any idea when this may be done?

quicksketch’s picture

Any idea when this may be done?

Not 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.

rbrownell’s picture

+1

rbrownell’s picture

I 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.

micheas’s picture

Yuck.

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.)

rbrownell’s picture

@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

quicksketch’s picture

quicksketch’s picture

Component: Code » User interface
Status: Active » Needs review

Here'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

David Stosik’s picture

Hello,

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

quicksketch’s picture

Well 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.

quicksketch’s picture

Ah, that patch was missing the new webform.conditionals.inc file. Again with the new file added.

PieterDC’s picture

Just watched your screencast. Nice progress!

jay_N’s picture

Screencast 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.

fenstrat’s picture

Version: 7.x-3.9 » 6.x-3.x-dev

@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.

David Stosik’s picture

Version: 6.x-3.x-dev » 7.x-3.9

Quicksketch, 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 :

  • First, displaying many and/or dropdowns in the same rule, whereas all are linked is quite confusing. I'd better see one dropdown at top of the rule saying AND/OR group, but I have another suggestions, which implies more work, see next point.
  • Working on the UI of my multiple conditions feature last week, I decided to use a dragtable to list the conditions, and to add the possibility to create AND/OR groups, which are nestable, and eventually contain conditions. This allow to create more complex rules, such as (A OR B) AND (C OR D). If you want me to, I could try to enhance your patch to add this feature (including of course modifications on the CRUD side).
  • I can think of many use cases where the administrator would like to trigger a regular Drupal Action such as displaying a message with drupal_set_message(), or even any custom-developed action. Do you think such a feature could make it in here?
  • Considering triggered actions, checking a checkbox, a radio button, or choosing a value in a select list (or even filling any textfield), could be an interesting feature, don't you think ?

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

David Stosik’s picture

Version: 7.x-3.9 » 6.x-3.x-dev
quicksketch’s picture

First, displaying many and/or dropdowns in the same rule, whereas all are linked is quite confusing. I'd better see one dropdown at top of the rule saying AND/OR group, but I have another suggestions, which implies more work, see next point.

Maybe, 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.

Working on the UI of my multiple conditions feature last week, I decided to use a dragtable to list the conditions, and to add the possibility to create AND/OR groups, which are nestable, and eventually contain conditions. This allow to create more complex rules, such as (A OR B) AND (C OR D). If you want me to, I could try to enhance your patch to add this feature (including of course modifications on the CRUD side).

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.

I can think of many use cases where the administrator would like to trigger a regular Drupal Action such as displaying a message with drupal_set_message(), or even any custom-developed action. Do you think such a feature could make it in here?

While an obviously related task, I'm not sure I want to attempt an arbitrary condition/action system at this point.

quicksketch’s picture

FileSize
81.67 KB

Followup on my own comment above:

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.

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.

fenstrat’s picture

Fantastic 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

quicksketch’s picture

Title: Multiple conditional rules » Multiple and same-page conditional rules
tedbow’s picture

@quicksketch,
Tried to patch d6 but get this error:

webform_conditional-d6.patch:1424: trailing whitespace.
conditionalResult = filteredResults.length === conditionalResults.length;
webform_conditional-d6.patch:1611: trailing whitespace.

webform_conditional-d6.patch:1615: trailing whitespace.

webform_conditional-d6.patch:2196: trailing whitespace.
$conditional_result = count($filtered_results) === count($conditional_results);
fatal: corrupt patch at line 2283

UPDATE: OK fix "corrupt" error by adding new line at the end of the file

MustangGB’s picture

#9
Yay! quicksketch is teh awesomesauce (=

tedbow’s picture

@quicksketch,
I am getting an error:

PHP Fatal error: Call to undefined function stricmp() in ...../sites/all/modules/webform/includes/webform.conditionals.inc on line 844

I am using PHP 5.3. The function should be "strcasecmp", right?

tedbow’s picture

@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

quicksketch’s picture

I am using PHP 5.3. The function should be "strcasecmp", right?

Yes 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.

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.

Hm, true. Though of course you could use a fieldset (or page) to hide a group all at once.

tedbow’s picture

Hm, true. Though of course you could use a fieldset (or page) to hide a group all at once.

Yeah 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).

David Stosik’s picture

Hi,
I tried the patch too. That sounds great, but may I share some remarks ?

  • First, the Webform displays nothing if no condition exists. I guess this could be fixed easily.
  • When setting a condition hiding a field when a radio button is selected, the opposite condition (showing the same field, when other radio buttons are selected). For example, I set a condition "In select field Mr/Ms/Mrs, when 'Mr' is not selected, show markup field 'You are a woman'. I think I should not need to create the opposite rule "Hide 'You are a woman' when 'Mr' is selected". But I am wondering if such thing is possible.
    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.
  • Is it planned to allow to plug custom conditions or actions on this system ?

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

quicksketch’s picture

Thanks for the testing and reports.

First, the Webform displays nothing if no condition exists.

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.

I think I should not need to create the opposite rule

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.

Is it planned to allow to plug custom conditions or actions on this system ?

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.

quicksketch’s picture

Version: 6.x-3.x-dev » 7.x-4.x-dev
FileSize
53.82 KB
50.4 KB
162.04 KB

Here'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.

quicksketch’s picture

FileSize
161.95 KB

Minor update fixes a display issue with the conditional form for dates.

fenstrat’s picture

Status: Needs review » Needs work
FileSize
98.84 KB

Fantastic work Nate!

  1. #32 and #31 both recursivly included webform_conditionals-d7.patch in the patch. The attached is a simple reroll of #32 and also fixes 4 whitespace errors picked up by git/dreditor.
  2. $submission->data[$cid]['value'] => $submission->data[$cid] makes a lot of sense.
  3. and/or ui looks good. I'd actually go with the 2nd option as having multiple options linked which are hardwired together seems odd. Playing devils advocate, have you thought about how views does this? It places the operator for the group at left. Not sure it'd be ideal but it's worth a thought. What you've got now makes it very readable from left to right in plain english (e.g. If Component Foo is ABC or Component Foo is DEF then hide Component Bar).
  4. When the conditional component is a checkbox or radio buttons they don't work. Change them to select lists and everything is fine.
  5. I've not done any multi page conditions, but in general this is looking really good.
quicksketch’s picture

FileSize
115.37 KB

Thanks 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.

tedbow’s picture

@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!

fenstrat’s picture

Status: Needs work » Needs review
FileSize
119.19 KB

Attached 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.

quicksketch’s picture

FileSize
108.71 KB

The 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.

quicksketch’s picture

FileSize
108.74 KB

Merge of #36 and #37 together to incude the spacing fixes.

quicksketch’s picture

FileSize
122.69 KB

Updated 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.

quicksketch’s picture

FileSize
127.13 KB

Same 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.

chertzog’s picture

When i try and do a git apply to the latest 7.x-4.x i get a error

fatal: corrupt patch at line 3419

Seeing as that line correspondes to

+/**
  * Disable the Drupal page cache.
  */   <----- This is line 3419
 function webform_disable_page_cache() {

Im assuming its a problem somewhere else.

quicksketch’s picture

I'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.

fenstrat’s picture

Yeah 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. However patch -p1 does work.

Also, solid work on those tests!

quicksketch’s picture

Status: Needs review » Fixed

To 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

fenstrat’s picture

Excellent 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.

quicksketch’s picture

@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.

fenstrat’s picture

@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

Upchuk’s picture

Hello,
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

quicksketch’s picture

@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.

Upchuk’s picture

Quicksketch,

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

Upchuk’s picture

@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

fenstrat’s picture

@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

quicksketch’s picture

@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.

quicksketch’s picture

Actually looks like someone already created an issue with an accurate description over here: #1619704: Conditions on a selection list field are reverted when editing.

quicksketch’s picture

esspecially considering as there's mainly SimpleTest's remaining todo

I 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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Upchuk’s picture

@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

alex.skrypnyk’s picture

@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.

VinceThePrince’s picture

I 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 :

if device equal iPhone and damage equal Screen.
price_estimate = 50 euro
endif

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.