Multiple target components for each conditional

"If no skip the next 5 pages", so there are around 30 conditional actions all based off this one condition.

This doesn't entirely solve the original request, but it could make life easier for you: You could select the page breaks to be the target of the conditional instead of the fields, so you would only need 5 conditions instead of 30.

Cross-referencing #1795936: Multiple Show / Hide Conditional.

A little followup to Alan's post (which had some great feature requests).

The way the conditionals work now, you can add a second requirement for the action to take place:

Clicking the "+" gives you:

Would it be possible to add a second set of "-/+"-buttons to a conditional to also add an extra action?

Perhaps something like:

that would either result in

or

?

Hi guys, yes of course "it's possible" but it's a matter of implementation difficulty. Right now we have a many-to-one relationship between conditionals and actions, and this would require a many-to-many relationship, meaning we'd need to add a 3rd table: webform_conditional, webform_conditional_rules, and (the new table) webform_conditional_targets.

I'm happy to look at patches for this feature, but I probably won't give it a priority for a while.

Thanks @MilOrg for the excellent screenshot demonstrating the desired functionality.

I really need this functionality. Right now I am trying to code an inspection form, so that the user can specify the number of individual locations that need inspection. Each location has the same things that need checked, but the number of locations can range from say 1-60. I need to be able to specify the number of fieldsets based on the number of locations indicated by the user. The only way I think that can work now is if I could add multiple conditions based on a single trigger, rather than the other way around. Or I could create 60 different pages, but that's cumbersome. Unless there's another way, I would love this to work.

Is there any news on this? I too could greatly benefit from this feature.

This is a good idea that awaits a patch. I'm not sure that I agree with quicksketch that another table is needed. We already have code that processes the conditionals to determine which fields need to be sent to the browser. The soft rule would still be that each component is at most a target of one conditional (otherwise a warning is issued). It's just that a conditional could have multiple targets, all of which can't appear in another conditional.

BTW, if the targets are grouped in a fieldset, hiding the fieldset hides all its children. This is an implicit variation on this feature.

Also note that this feature may interact with the feature to use conditionals to set values.

This is a good idea and more implementable now that conditionals work in dependency order. Despite what I said in #10, we would need to add another table for the actions and a hook_update_N to migrate the single target from the rule group to the actions table. Code for deleting components would need to delete them from actions too, including deleting actions that no longer have any targets. And of course the code to analyze dependencies, execute conditionals in the server, and execute conditionals in the browser will all need adjusting.

The design in #5 is the right way to go. This sets the stage for actions other than show/hide.

Somewhat related, I'd like the show/hide to be changed to when the condition is true/false SHOW the component. This sets the stage for changing components with conditionals.

Another big patch.

webform.components.inc.

1. The code which handles deleting portions or all of a conditional when the component is deleted was updated for when the component is used as one of possibly many actions. In addition a subtle bug where a component may be used more than once as a source was fixed. (E.g. if a=1 or a=2 then hide b).

webform.conditional.inc.

1. Conditionals with the last action removed are removed from the form, matching the code for removing the last rule.
2. A new rule has an array of actions, rather than one target/action
3. Form validation for defining conditions was updated for any of its targets' components being any of its rules' components. In addition, you can't use a target in more than one action of a conditional.
4. Saving conditionals create an array of actions, rather than just one.
5. The conditional for was adjusted to allow adding/removing multiple actions.
6. The code which responds to an ajax + or - was fixed. There was a bug causing a NULL reference when removing the last conditional. Users would typically not see the PHP notice because ajax operations don't display them.
7. The code for expanding a condition and theming it was modified to cope with multiple actions.
8. Actions are written to a separate table.
9. A deleted conditional deletes its actions from a separate table.
10. The javascript setting sent to the browser for the client form includes an array of actions.

webform.webformconditionals.inc

1. The rules were enhanced to allow for an array of actions (i.e. targets), rather than just one.
2. The code to execute the conditionals on submission data was enhanced to allow an array of actions.

webform-admin.js

1. The code to remove the entire row from the table was enhanced to also do this when the last action is removed. Due to running jquery 1.4, this was harder than expected due to the lack of $.proxy(function, context, extraarg).

webform.js

1. The code to execute conditionals was enhanced for an array of actions.

webform.install

1. A new table was added to the schema to store actions (webform_condtional_actions). I picked a plural name to match webform_conditional_rules, although I prefer table names to be singular. This table contains two extra columns for future use: invert (to provide an "else" option) and argument (to provide an argument for setting actions, such as set a = 1.
2. A hook_update_N was added which creates this table, copies the data from webform_conditional into it, drops the unneeded columns from webform_conditional, and rebuilds the class registry. This last step will help site upgrading to the main conditional function, where core needs to discover WebformConditionals.

webform.module

1. The webform_conditional_actions table is removed upon uninstall.
2. The actions are loaded from the new table upon loading the webform node.
3. The code for performing a rule check on adding components to the client form was enhanced to multiple actions.

Hopefully this patch will get a review. This patch is needed to continue work on other conditional issues.

Setting back to Needs Review, but clearly the tests need updating. (I'm hoping this won't re-trigger the testbot.)

Let's try this again. One part fixed tests to adapt to multiple targets, one part fix webform to correctly evaluate multiple targets in server. This check rule code really needs to get simplified using the data for the topological sort, but this patch has to go in first.

The conditional test pass on my development server now. First time since my involvement in webform that they've been helpful. I'm not sure what to think of that.

Revised only in that the update message suggests a backup before proceeding.

I have committed this locally to allow development to continue on related issues. I won't push it until it's had a little more time to see if it attracts any comments.

I have applied the patch however when i go to the conditional tab of the webform I receive a Fatal error: Class 'WebformConditionals' not found in on line 3824.

Re #17 -- Just to confirm -- you are applying the patch for testing purposes only, not for use in production. This patch or the implementation may well change or even never be committed (unlikely).

This patch should be applied to the latest dev, which is 7.x-4.6+6-dev

If you are getting that Fatal error, either you haven't cleared your cache or you applied the patch to an older version of webform.

This patch requires that you run update.php or drush updatedb. The update makes non-reversible changes to the database schema. Be sure you have a backup you can restore.

I am obviously doing something very wrong and I imagine it is something very simple I have missed. The patch file is located in the most current directory of webform. I use git apply patchname.patch and nothing occurs? I receive the following error.

patch.name:719: trailing whitespace.

warning: 1 line adds whitespace errors.

This is being patched locally in development, on receipt of the error no files have been changed. I have spent hours and I thought it had worked then had issues with the patch working.

@mitch147,

1. Ensure that git is installed properly and working.
2. Clone the repository into a the module directory of your choice (e.g. sites/all/modules) following the directions from the module page: https://www.drupal.org/node/7404/git-instructions/7.x-4.x/nonmaintainer
3. Apply the patch following these instructions: https://www.drupal.org/node/1399218

This patch can currently be applied to the head of the 7.x-4.x branch.

I have solved the patching issue, it was associated with being on the wrong branch. I have attempted to apply a conditional with 3 targets and resulted in the following error:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'infit.webform_conditional_actions' doesn't exist: INSERT INTO {webform_conditional_actions} (nid, rgid, aid, target_type, target, action) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => 0 [:db_insert_placeholder_2] => 0 [:db_insert_placeholder_3] => component [:db_insert_placeholder_4] => 3 [:db_insert_placeholder_5] => hide ) in drupal_write_record() (line 7239 of C:\Users\mitch\Sites\devdesktop\infit\includes\common.inc).

What has caused this exception?

You didn't run update.php.

Thankyou, the patch is now functioning correctly. From a functionality point of view, I have one more query.

An example:
I have a listbox with three numbers (1,2 and 3). These numbers correspond to showing three fieldsets. I have tried different conditions to achieve this however am still not able to and I originally thought this patch was my solution.

The following are the conditions I am trying to apply:
1. When the listbox is empty none of the three fieldsets are showing.
2. When the number '1' is slected from the listbox the first field set is showing and fieldset '2' and '3' are hidden.
3. When the number '2' is slected from the listbox the first and second field set are showing and fieldset '3' remains hidden.
4. When the number '3' is slected from the listbox the first second and third field are showing with none hidden.

I have tried different logic to attack this however I believe the issue is associated with sequencing the conditons. I am unsure of a solution. My solution (im not but a humble reliability engineer) is perhaps to allow multiple fields to be hidden under one condition and if the condition is not true then that condition is ignored irrespective of the sequencing.

Sequencing is now irrelevant. Webform analyzes the dependencies in the list of conditionals and build a correct sequence so that when a conditional is evaluated, all its source components have already been evaluated.

When you hide a fieldset, it hides everything in it.

What you want is

if s =1 or s = 2 or s = 3 then show fieldset a
if s = 2 or s = 3 then show fieldset b
if s = 3 then show fieldset c

Three different conditional groups, unrelated to this issue.

Resolved upstream conflicts and committed to 7.x-4.x.

Needs port to D8. fenstrat -- For the 4 pending conditional patches, apply this one 1st.

Committed and pushed to 8.x-4.x. Thanks!

Small problem with the hook_update. The argument wasn't being set to an empty string, and text fields can't have defaults.

Committed to 7.x-4.x. No D8 port needed because it is an hook_update function.