Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Here is a patch to get the status of a webform into views' filter.
Hope this could help.
Comment | File | Size | Author |
---|---|---|---|
#27 | add_a_views_handler-1110444-27.patch | 399 bytes | visabhishek |
#24 | webform_status_field_1110444_21.patch | 450 bytes | joshuautley |
#22 | webform_status_field_1110444_21.patch | 502 bytes | joshuautley |
#13 | webform_status_field-d6.patch | 7.46 KB | quicksketch |
#13 | webform_status_field-d7.patch | 7.46 KB | quicksketch |
Comments
Comment #1
harrrrrrr CreditAttribution: harrrrrrr commentedTested and approved.
Comment #2
harrrrrrr CreditAttribution: harrrrrrr commentedComment #3
quicksketchThe name of this category should probably be just "Webform". "infos" is not a real word.
Should be "Status".
We should write a custom handler for "Active" or "Inactive" to be displayed instead of 0 or 1 for the field value, just like the Node Published/Unpublished field and filter. Using the numeric handler is functional but lazy.
Comment #4
jweowu CreditAttribution: jweowu commentedHere's a re-roll of the original patch (edit: for 7.x-3.15). I've fixed the language issues, but haven't implemented a custom handler.
I've also changed the join to an inner join, because an outer join was unnecessary (for the query being generated).
An outer join might potentially be desirable, as no row is added to the webform table until a form component is created. However the View would need to be testing the specified value against
COALESCE(webform.status, 0)
or similar for a left join to actually return those rows. A NULL webform probably shouldn't be considered equivalent to a closed webform, though.Comment #5
jweowu CreditAttribution: jweowu commentededit: Oops.
Comment #6
jweowu CreditAttribution: jweowu commentedAh, I had meant to set that to 7.x-3.15. I saw the 6.x-3.9 » 7.x-3.11 change in #1, didn't notice that it had been changed back in #2, and managed to just adjust the minor number without even noticing the major number. So to clarify, the original patch was for Drupal 6, and the patch in #4 is for Drupal 7.
Comment #7
quicksketchThe latest patch works on both D6 and D7 without changes.
This patch needs a dedicated handler for Open/Closed status for both the field and filter. The comment module Views integration provides a pretty good example of how to do this with minimal effort.
Comment #8
bdone CreditAttribution: bdone commentedhere's a patch against 6.x-3.x that includes...
Comment #9
bdone CreditAttribution: bdone commentedhere's the same patch against 7.x-3.x and a view export for testing
Comment #10
bdone CreditAttribution: bdone commenteddo these patches need anything else for a review?
Comment #11
quicksketchThe D6 patch doesn't seem compatible with Views 2 on Drupal 6. Was this written against Views 3?
The D7 patch worked pretty well but the type (open/closed, yes/no, etc.) would always revert back to open/close when editing. I've fixed that problem in this iteration.
This patch also makes a new "Webform" group in Views, but we're currently piggy-backing off the "Node" or "Content" groups for things like the Webform Edit and Results links. I think it'd make sense to convert these all to the "Webform" group, or we can keep using the existing groups. We shouldn't split between two different locations though.
Comment #12
quicksketchDoh, apparently I just forgot to add the new files to the webform/views directory. Patch worked fine in Views 2 after that minor fix. I'll look into the minor cleanup and post an updated patch.
Comment #13
quicksketchUpdated patches that simply move all the Webform fields into a common category.
Comment #15
joshuautley CreditAttribution: joshuautley commentedany reason the field "status" is causing inner joins? And can there be a way to change to a left join in the views UI via a reduce duplicates?
I'm looking at... webform.views.inc - line: 19 - 25 (specifically line 23)
Returns: INNER JOIN {webform} webform ON node.nid = webform.nid
So, I changed line 23 to "LEFT" instead of "INNER" as shown below...
Which returns: LEFT JOIN {webform} webform ON node.nid = webform.nid
Is there any objection to why I should not do this? And if no objection can this be changed?
Comment #16
joshuautley CreditAttribution: joshuautley commentedComment #17
jweowu CreditAttribution: jweowu commentedI don't remember details of this issue, but my comment #4 above is why it's an inner join in the code.
Things may well have changed in the intervening years, so it's probably best if you explain why an outer join is desirable?
Comment #18
DanChadwick CreditAttribution: DanChadwick commentedMy feeling is that the webform views integration is only intended to be executed on webform nodes, and if submissions are displayed, only on the same webform as was used to define the view, a clone of that webform, or a carefully-crafted webform with identical form_keys.
Since an inner join is faster than an outer join and since god knows what bugs there might be if the view were executed on non-webform nodes, my inclination is to leave this as is.
If the poster wants a view that operations on both webform and non-webform nodes, it might be best to write a custom views handler, or to use hook_views_data_alter() as desired.
I think we should mark this works-as-designed.
Comment #19
joshuautley CreditAttribution: joshuautley commented@jweowu
An example use case:
I'd like to display both a node and a webform title but I only want to display Open webforms -or- I'd at least like to display the status of the webform as Open or Closed.
Make sense?
And to be more specific here is why I need a LEFT join instead of INNER
I have Webforms and EntityForms. I need to display a list of titles for both and I need to sort on that list.
Comment #20
joshuautley CreditAttribution: joshuautley commented@DanChadwick
To be clear I'm proposing a "LEFT" join not an OUTER join.
Comment #21
therealwebguy CreditAttribution: therealwebguy commentedThis can quickly be solved by making the Status field provided by webform a LEFT JOIN (you don't want to INNER JOIN this since it won't support any inclusion of other node types)
becomes:
Comment #22
joshuautley CreditAttribution: joshuautley commentedPatch for #21 - Please review.
Comment #24
joshuautley CreditAttribution: joshuautley commentedTrying this again
Comment #25
visabhishek CreditAttribution: visabhishek as a volunteer and at Azri Solutions commentedi am changing status to Needs review with Latest dev branch.
Comment #27
visabhishek CreditAttribution: visabhishek as a volunteer and at Azri Solutions commentedRe-rolled patch for #24
Comment #28
DanChadwick CreditAttribution: DanChadwick commentedUsing the webform views integration on non-webform nodes is outside the use case for webform core. Fortunately, Drupal/Views provides a hook for exactly this situation -- hook_views_data_data(). This will easily allow you to adjust the join and/or add a status field without accessing it via the webform table's view definition -- whichever solution you prefer.
Putting status and version back to the 3-year old original issue. This discussion should have taken place in a new issue anyhow.
Comment #29
therealwebguy CreditAttribution: therealwebguy commented@DanChadwick - Happy to take this discussion to another thread, but I'd like to better understand your position that this is a non-webform issue. Webform provides views support for its Status field, but does not correctly define its join, forcing its inclusion to INNER JOIN every time. This prevents any conditional querying on anything outside of webform. Thats simply poor design.
If webform is going to provide views integration for a field it defines, it should then be responsible for accurate query definitions. I say all of this with the utmost respect and am in no way interested in starting a debate, I just struggle a bit with the notion that the solution is to leverage hooks programmatically when this is already supported by views.
Comment #30
jweowu CreditAttribution: jweowu commentedThat's an OUTER join. A "LEFT" join is shorthand for "LEFT OUTER JOIN", just like a "RIGHT" join is a "RIGHT OUTER JOIN".
Comment #31
joshuautley CreditAttribution: joshuautley commented@ #30
Ah. Thank you for the clarification on the shorthand.