When the view is defined, webform_handler_relationship_submission_data refers to a particular webform node and component and saves the node's nid and the component's cid in the view. This limits the view to being used with this one webform.
There are use cases where the same component might be defined in many webforms. In my case, I have many webforms which are either clones of each other or which share portions. Webform does not offer a immutable machine id for components, but it does have a form key.
So long as the form key is unique within the webform (which webform does not enforce because of component nesting), the form key may be used in the relationship. The requires an extra join to the webform_component table, but it decouples the view from a specific node and component.
This would give the the component the same same sort of flexibility in filter and sort that it already has in displaying submission data (where to form key is used to find a component in a different webform from the one used to define the view).
The proposed implementation would be to save not only the nid and cid, but the form key, as well as a preference for using the nid+cid or form key.
Anyone else interested in this feature?
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | webform-join_by_form_key-2996933-3.patch | 1.09 KB | possibri |
| #11 | webform_views_why_nid_required_for_field.png | 56.7 KB | chris burge |
| #11 | webform_views_relationship_why_node_required.png | 86.05 KB | chris burge |
| #3 | webform-join_by_form_key-2996933-2.patch | 5.42 KB | danchadwick |
Comments
Comment #2
liam morlandSounds like it could be useful.
Comment #3
danchadwick commentedHere's an implementation that allows the relationship to join by nid+cid (old behavior), cid only, and form_key.
Liam - I know this patch uses a bit of non-standard indentation, but the views calls have so many parameters and the documentation is so hard to find that I though it was worthwhile to comment every argument.
Comment #5
danchadwick commentedCommitted to 7.x-4.x
Comment #7
chris burge commentedWould you consider this a functional equivalent of #2506429: Provide Option to Key on 'form_key' in Webform Submission Views?
Comment #8
danchadwick commentedChris - seems like it. I did not see your issue when I did this work. If the current capability meets your needs, I suggest you close the other issue. Otherwise maybe clarify?
Comment #9
chris burge commentedDan - It looks like I can close the related issue as a duplicate of this one. I'll need to do some testing first.
Comment #10
chris burge commentedComment #11
chris burge commentedIf this patch seeks to decouple a view from a particular Webform node, then why is a node required when recreating a relationship using a component form key?
Even with the relationship, why is a node required when adding a 'Webform submission data: Value' field in the view?
These constraints prevent the view from functioning independent of a particular Webform node.
Comment #12
danchadwick commentedChris -- I haven't looked at the code again, but I believe this is a "prototype" webform, which among other things facilitates the user interface of selecting the component by its title, rather than a list of form keys or cid's. In other words, the view should work, but you need one webform to define it.
Comment #13
chris burge commentedThat makes sense then. I'm leaving #2506429: Provide Option to Key on 'form_key' in Webform Submission Views open as it allows a site builder to decouple a view from a source node. A site builder can manually enter the form key. This makes the view portable (i.e. you can deploy it with Features without it breaking).
Comment #14
possibri@Dan, thanks for getting the patch into the latest release! I found a small typo that breaks the form_key option (Line 62 in webform_handler_relationship_submission_data.inc):
$options['webform_form_key'] = $options['webform_join_by_form_key'] == 'form_key' && ($node = node_load($options['webform_nid']))The initial if condition is checking "webform_join_by_form_key" but in the options form this component is defined as "webform_join_by" so it never returns true.
Thanks!
Comment #15
danchadwick commented@possiBri - can you post a patch, please?
Comment #16
possibri@Dan I've never done an official patch before, so I'm not sure if I've created it correctly... so I hope this works!
Comment #18
danchadwick commented@possiBri - Close on the patch. It was made at the wrong directory level and so couldn't be applied. I just made the change by hand. Thanks for fixing this. In my application, I generate the views dynamically, rather than using the UI. I must have changed the option's name at some point and missed the submit handler. I did a quick test and your change seems to work. Please download the dev after the above commit and confirm. Also, congratulations on your first commit.
Comment #19
possibri@DanChadwick Thanks for the pointer about the commit, I'll make sure I'm in the proper directory next time! Also I've got the dev version installed and everything seems to be working as expected. Thanks for all your work on this module!
Comment #21
gbirch commentedDoes this patch actually solve the issue as described? When adding the relationship, the handler UI still requires you to specify one particular webform NID. What am I missing?