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.
I was wondering if it possible to display the webform fields in a view? I'd like to build a custom list of results that would be available to mutliple users (anonymous or not) without giving them access to view the results in the webform module.
Thank you,
Shane
Comment | File | Size | Author |
---|---|---|---|
#95 | (Admin) All Submissions - Webform View | 52.91 KB | djalloway |
#95 | (User) My Submissions - Webform View | 39.3 KB | djalloway |
#91 | webform-273837-91.patch | 12.79 KB | djalloway |
#69 | webform-273837-69.patch | 11.87 KB | djalloway |
#62 | webform-273837-62.patch | 12.25 KB | djalloway |
Comments
Comment #1
quicksketchWebform submissions are not nodes, and therefor cannot be integrated in any way with Views (in Drupal 5). Even though this may be possible in Drupal 6, I'd highly discourage the use of Views with Webform because Webform's datastorage is not meant to retrieve multiple individual records (it's either one or all).
As posted on the project page form Webform, if you need the flexibility of Views or other add-in modules, CCK is a better route than Webform.
Comment #2
alanburke CreditAttribution: alanburke commentedTheoretically possible with Views 2 in Drupal 6.
Bumping version.
Comment #3
quicksketchThere's been a lot of buzz around Views 2 (for Drupal 6) and Webform integration. As Views can now display any data (not just nodes) it becomes possible to integrate Views and Webform, making lists of any data stored in Webform customizable. This feature will not be included in the Drupal 5 version, as technical limitations of Views 1 prevent this from being possible.
I'm generally still against this proposal, since I think it means that users will only use Webform in more inappropriate ways that have crippling performance impacts. But, I understand from a large number of requests that this is a desirable feature and can be used in many ways that are helpful but not devastating to site performance (such as admin-only views). So I'm up for including integration, though I have no timeline for writing it myself. Patches gladly accepted, though they'll need to be extra-clean, as Views integrations can be somewhat convoluted.
Comment #4
quicksketchComment #5
shanefjordan CreditAttribution: shanefjordan commentedI would recommend instead of convoluting the Webforms project to make this into an add-on module to webform. This would make it so that users that don't want that extra overhead wouldn't have it, but on the other hand the ones that would want the integration could have it added.
- Shane
Comment #6
marie_t CreditAttribution: marie_t commentedSubscribing, I also desperately need this functionality. I may be willing to sponsor the development of an add-on module depending on the cost. Is there anyone out there willing to work on this?
Comment #7
quicksketchEclipseGC (author of Webform Associate) has mentioned to me he's interested in working on this. You might reach out to him to see if he's needing funding to put aside existing projects to work on this.
Comment #8
mrfelton CreditAttribution: mrfelton commentedinteresting idea and I'm all for it.
Comment #9
Chris CharltonSubscribing.
Comment #10
3CWebDev CreditAttribution: 3CWebDev commentedsub
Comment #11
matt2000 CreditAttribution: matt2000 commentedAlso subscribing.
Although my Views-integration experience is fairly elementary at this point, I would consider taking on this project under sponsorship and/or collaborating with other coders to get this done.
Comment #12
greg@beargroup.com CreditAttribution: greg@beargroup.com commentedAs a bit of a use case for this idea. Recently created a site (www.viscountstudios.com) that needed a very simple registration system. So implemented a webform for each dance class and restricted the user access so people create user accounts. All works great for their purposes.
Where views would have been very handy is in admin-side reporting. The reports they wanted include specific webform registration fields, and also wanted to merge that with user profile data. So to do that ended up with an override of theme_webform_results_submissions to call in the specific fields and customize the output. This wasn't too much work, but would have been easier to whip out a view. I could see a single view with exposed filters where they can see the registration line items (either per webform node, or in this case since the webform fields are all the same, it could be 1 report). If any created webform field was registered for use in views, this type of reporting could be quickly accomplished.
The other admin side report that could be done in views I think would be a rollup - since they have 20+ webforms, nice to see a view that summarized the results (#/session). Again with nice exposed filters so a single report could serve the purpose of all webforms created (that works in this case since the webform fields are all the same).
Also had to create a block that I showed on each user profile page showing what they have registered for, this could be a view. Plus could get RSS feeds or perhaps latest submissions blocks and think of other ways to use this.
So could almost entirely replace what is in webform_report.inc, with support for Views. (With the exception of CSV export, which I don't think views supports currently, maybe there is an addon for that). Would get the benefits of views, easier theming, merging in other user/profile fields with the submission data, being selective about which webform fields are shown in reports - all greatly extends the reporting functions, and would make it easier for non-coders to have custom webform reports.
So +1 for a views / webform integration!
Thanks,
-Greg
Comment #13
asak CreditAttribution: asak commentedSubscribing! ;)
Comment #14
wuf31 CreditAttribution: wuf31 commentedSubscribing! :)
Comment #15
bwoods CreditAttribution: bwoods commentedSubscribing
Comment #16
Jim Ruby CreditAttribution: Jim Ruby commentedsubscribing
Comment #17
k3vin CreditAttribution: k3vin commentedsubscribing
Comment #18
latte CreditAttribution: latte commentedThis will be a great plugin.
Comment #19
gausarts CreditAttribution: gausarts commentedwow it's so exciting. allow me to subscribe, thanks
Comment #20
KrisBulman CreditAttribution: KrisBulman commentedany movement on this?
Comment #21
Anonymous (not verified) CreditAttribution: Anonymous commentedsubscribing..
I'd imagine views could be used to generate a random selection/shortlist from all submissions.
Comment #22
InternetDevels CreditAttribution: InternetDevels commentedsubs
Comment #23
Panda_N_Shark CreditAttribution: Panda_N_Shark commentedsubscribing.
Comment #24
grey_ CreditAttribution: grey_ commentedsubscribing
Comment #25
Jim Ruby CreditAttribution: Jim Ruby commentedsubscribing - any progress? Thank you. Looking forward to this.
Comment #26
sunset_bill CreditAttribution: sunset_bill commentedThis doesn't do anything with Views so I don't know how useful it might be for everybody concerned, but here's a hack on webform.module to show a webform's Results > Analysis to non-admin users, while the admin still gets all the reporting options. Sorry it's not something cooler like a patch, but I don't know how to do those. ;^)
First, add an 'access simple results' option in webform_perm()
In webform_menu(), change the access arguments in webform-results and webform-results/analysis items to 'access simple results', and change the MENU_DEFAULT_LOCAL_TASK from webform-results/submissions to webform-results/analysis.
Then, give authenticated and even anonymous users 'access simple results' permission.
Hope that helps a few at least.
salud,
Bill
Comment #27
taxicab221 CreditAttribution: taxicab221 commentedsubscribing
Comment #28
djalloway CreditAttribution: djalloway commentedI've taken an attempt at writing the necessary code to expose Webform submissions to Views using it's 2.0 API.
Please note that the functionality appears as additional fields / filters & sorts under the following base view types.
I have not defined Webform Submissions as it's own base type within Views, because it's more of a relational type data on top of existing base objects like Users + Nodes.
I'm new at this whole patch submission thing, so I hope I've done it all correctly.
I believe I created this patch off of the DRUPAL-6--2-6 version of Webforms, once again I'm very new to this and have no idea what I'm doing.
**Please note that there are two new files in this patch that should be created, but the problem is that I don't know if CVS will make the appropiate sub-directory, they should end up in "webform/views/" but if they don't I will need someone to help me with this.**
What I am looking for here is help and support to move this along and bring more functionality to it.
Thanks!
Comment #29
djalloway CreditAttribution: djalloway commentedOk, yea, the patch file I submitted does not apply correctly.
I'll take another swing at it and re-post it.
Comment #30
djalloway CreditAttribution: djalloway commentedI've figured out how create a patch in CVS that contains new directories and files now.
Attached is the working copy of my patch.
This patch should do the following.
The command I used to successfully apply the patch when I tested it was.
patch -p0 < webform-273837-30.patch
assuming that you downloaded the patch to the same directory as your webform module.
Comment #31
quicksketchThanks djalloway! Against CVS too! I really appreciate the effort you put into getting this into patch form.
- Code style looks real good, thanks for that.
- Obviously we'll need to make some special handlers for display of several fields, such as dates, since their data is currently spread across 3 rows and select lists, since they (optionally) need to be converted to their readable values instead of machine values.
- I like how this patch is very self-contained currently. If you need more functionality in Webform that doesn't exist currently, please open a new issue for that functionality and keep this one focused on Views integration.
I think making submissions a base table would make a lot of sense in this situation. The question most people will ask when creating a new view is "What am I making a listing of?" I think when "Webform submissions" is the answer, it makes more sense to start directly with a base table of the same name rather than starting with user or node. Plus the much smaller set of addable options should make things easier for users making lists of submissions without having to deal with the extensive number of node-based fields, filters, sort criteria, etc.
Overall, this looks like a great start. I'm fine with committing things as you go along too, once we get to good stopping points.
Comment #32
djalloway CreditAttribution: djalloway commentedGood stuff.
The funny thing is that I actually have a copy of the code with Webform submissions as a Views base table, as the thought definitely came up in the coding, it is something I can very easily bring back in.
It's going to take me a bit of time to become more familiar with the Views API to be able to get most of the functionality in.
But the good part is that with such a self contained module, the effort can be very very easily split up and accomplished in a progression style.
So one piece at a time, I'll start with committing the code with Webform submission as a base table.
This project coincides with a current work project I am on, so the time I spend on this, at least for the next few weeks is interchangeable, so I'm going to get as much done as possible while it's in my best interest.
Comment #33
djalloway CreditAttribution: djalloway commentedDone.
Created edit & delete link handlers for submissions, the delete handler returns you to the correct location after the delete as well.
**NOTE / QUESTION**
I rolled this patch against a clean copy of Webform, is this the correct way to re-post a patch?
Comment #34
quicksketchYep, just keep rolling the entire thing against the DRUPAL-6--2 branch until it gets committed. :)
The link handlers look great so far. I'm glad to see that you made generic handler for links and then extended it in two different ways for delete and edit. You are wise in the ways of OO. :-)
These access functions look a little off though:
This won't work for users that need to edit their own submissions for example. It looks like the typical way to do this is to set an "access callback" on the field itself in hook_views_data().
Then remove your access() method and fallback to the Views default one.
Comment #35
djalloway CreditAttribution: djalloway commentedKey notes.
As far as relationships go, please refer to #380560: Fatal error: Call to a member function get_handlers() before using them, as there is an AJAX bug when trying to add a field made available by a relationship.
Comment #36
djalloway CreditAttribution: djalloway commentedIt doesn't seem like I can call the access checks from within the field definitions.
Not even from the
access()
function in the handler.The end result, as you can see in the above patch #35, is the access checks being handled in the
render()
handler function.Until some more light can be shed on 'how' to do it a different way (specifically how to have the variables available I need to run the check), this is where I am at.
**Summary**
Once a firm foundation on all of this is built, I will move deeper and approach the task of getting actual form fields available for display.
Comment #37
cdale CreditAttribution: cdale commentedThis is looking pretty good djalloway. I actually have something similar that I'm working on. As far as the actual webform fields go, you are going to run into a few issues as the webform submitted data is stored using the EAV model. A good place to start looking is in how views does the profile module integration.
I should note, that because the data is stored using an EAV style model, sort handlers will degrade very very quickly in performance as submissions get added. For example, I have a sample form (Not a webform) that has about 50000 submissions, with 3 fields. This makes for 150000 records in the submitted data table, and sorting can take a very long time as there is no way the DB can use indexes due to the number of joins in views to get the fields in in the first place.
I'm working on ways around this for something else I'm doing, but it is not light coding, and it is certainly not a 'traditional' thing to do.
I've included below some of the approaches I've taken to include webform like integration with views. (I'm not actually doing mine for webform, but the model is identical).
Firstly, Webform has a unique set of components per node, and I wanted to be able to create a view per node, not for all submissions as a collective. In my model, I never actually joined on the node table because of this. To do this, I declare the base submissions table, then create a join for each webform node (with the real table being the submitted data table).
To help users select a particular node, I used a form alter on views_ui_add_form to add a select list of available nodes and placed it next to the radio button for the submissions base table. This allowed me to create a view for a specific node and I kept the nid on the view object for tracking purposes. (Needs to be loaded back up from your own 'views_weform' table to keep a record of which nid goes to which view).
Once you have that, you can then alter views_ui_add_item_form to limit the 'components' sent to views to be the ones for the node you are working on. (I'm assuming your hook_views_data has a naming convention that allows you to match a particular string.. i.e. create a join per webform as described above).
That should get yo up and working quite nicely, and should keep the ui mostly consistent.
*** Advanced stuff below ***
The extra stuff I'm working on at the moment, is actually creating a new table per view for performance reasons. This table is created from the fields/sorts/filters/relationships/arguments used in the view, to only include those columns, then when the view is saved, I run a batch operation to populate data out of the submissions table into the table for the view.
This is not very DRY, but the performance improvements I feel justify the move. For example, I took a views query on the EAV table with 50000 submissions of 13 seconds, down to 0.45 milliseconds with this model. This is probably not an issue for anything less than 5000 submissions, though this is very dependent on how many components in your webform, and how many components you have in your view. And as I said before, the problem is only really for sort handlers.
There is obviously a lot more going on, for example, my joins are different from what I describe above to achieve this, and I have some magic going on when creating/editing a view which creates a temporary table for the view to query whilst it is being made for the live preview.
I'm not sure if webform wants to take it this far, but if you like, I can throw up all 1000 lines of my views.inc file which has all of the views related code in it which does everything I've said above.
Comment #38
cdale CreditAttribution: cdale commentedI should add that I went one step further and added an extra checkbox option to each 'webform' to force the creator to make it views enabled (But only if they have the 'administer views' permission) to reduce clutter when creating views of a webform as quite frequently I have 'webforms' that I don't want or need views for.
Comment #39
djalloway CreditAttribution: djalloway commentedThanks for your reply and details cdale!
And yes! I was looking at the default views integration for profiles just a few minutes ago, thank you for the insight!
Unfortunately, when I started this I had feared this would be the case the deeper I went into this.
The silver lining is that even at the level this patch is right now, it is useful for a lot of people, that being just this basic top-level submission filtering.
Comment #40
djalloway CreditAttribution: djalloway commentedWhat about having two base view types?
The current one, handling all Webform Submissions collectively.
And another one, singular instead of plural, handling the actual form-fields on a per-node basis?
Or something to that extent, seeing how it would help keep things logically separated.
Comment #41
cdale CreditAttribution: cdale commentedI hadn't really considered using two base view types. It's not a bad idea. It would be useful to aggregate submission data across a collection of webforms. But it would certainly need to be a different base type.
Comment #42
djalloway CreditAttribution: djalloway commentedJust a quality control update patch.
Cleaned up Titles / Labels / Wording and overall "flow" and logic of the options that this patch opens up.
Next step will be to take a step downward and begin looking at actual Structure and Logic for Webform Fields in Views.
Comment #43
cdale CreditAttribution: cdale commenteddjalloway, it looks like your patches have the UTF8 BOM at the start of the new files you've made. You should probably look at creating a patch without them. :) It should be a setting in your editors config somewhere.
Comment #44
djalloway CreditAttribution: djalloway commentedWithout the BOM.
Comment #45
mukatira CreditAttribution: mukatira commentedThis patch has worked for me, in that I can see Webform Submissions as a "field" in Views. HOWEVER:
1. At this point I can only see the contents of http://www.example.com/nodenumber/webform-results. I am really interested in the contents of http://www.example.com/nodenumber/webform-results/table, since additional headers which were created by me (queries to which users reply) are visible here and this is what I want to be able to be viewed as page/block .....
2. I am unable to view other users submissions to the webform (like IP address, Date of submission, name etc..)
Thanks for the great work so far
Sm
Comment #46
cdale CreditAttribution: cdale commented@mukatira - 1. The viewing of webform-results/table would come from the integration of webform fields, which is no small task and has been discussed previously in this issue.
2. IP Address and Date of Submission should be fields available on the view, and the users name field can be retrieved by adding the users relationship to the view.
Comment #47
cdale CreditAttribution: cdale commentedI've been reviewing this patch, and I think the handlers can be simplified quite a bit. I'm not able to make a patch right now, but my idea would be along these lines:
1. Modify webform_handler_field_submission_link to the following:
2. Change the link definitions in hook_views_data() to include the link_type option on the field:
3. Delete all the extra edit/delete/view classes that were made.
Comment #48
Amir Simantov CreditAttribution: Amir Simantov commentedI have read it all and not sure... I am making a view in order to see all forms nicer than the tracker's defaults. I have the name of the form, its update date, etc. Now, regarding to submissions, I need only the NUMBER of submissions for each form to show in the view. Can I do it without changing the code or patching? If I must code/patch, which of the above proposals is enough for my small task?
Thanks!
Comment #49
djalloway CreditAttribution: djalloway commented@cdale,
Here is a patch with the changes you've recommended.
All the links are now contained in one handler, and use the
$link_type
variable to distinguish themselves.Comment #50
djalloway CreditAttribution: djalloway commented@Amir Simantov,
I've added a new custom field to the patch that gives the Node type a new field called 'Webform submission count'.
This did not exist before, so I don't know if you can get what you need any other way besides applying this patch, which I would not recommend doing on a production site at the moment.
Comment #51
Amir Simantov CreditAttribution: Amir Simantov commentedThanks djalloway but it did not work...
I get: a fatal error saying that the class 'views_handler_field' was not found.
I am using the latest views version: 6.x-2.3 (http://drupal.org/node/370526)
How can we fix it? Thanks for your help!
Comment #52
djalloway CreditAttribution: djalloway commentedAmir Simantov,
I'm going to need a bit more information then that.
Comment #53
djalloway CreditAttribution: djalloway commentedPreface
For those you just joining us...
So far we've accomplished making Webform data available on a "Submission" level only (see above patches) which is still very good for some people.
Now, we're currently looking into making Webform components available via Views fields (one level deeper).
Current Approach
Originally I was hoping to mimic how Views currently handles Profile fields to accomplish this.
One issue in trying to do it this way (on a 'per field' basis), is that potentially you'd be bringing in a LARGE number of components on a typical site that uses Webform.
This does not seem ideal.
Another idea / approach is having a single "Webform body" field, that contains the entire rendered "Form" body of a Webform, making it available for output in that way (sort of like Body for a node).
My Summary
Obviously people would like to output the actual "form" using Views, so having "Form Body" or something as a field, seems like the way to go, as doing it on a 'per field' basis where each component is available as Views field, is continuing to look like it just isn't going to work and even if it does work, not be very efficient / practical or logical on medium to large scale.
What I'm Looking For
Thoughts? Ideas? Differential Logic? Patches? Hot Cup of Coffee?
Comment #54
Amir Simantov CreditAttribution: Amir Simantov commentedHi djalloway,
It is not a clean install but rather a customized webform code I made. However, the Views code is "clean" but does not have the said class - and this is where is looks for it.
So, what I did is copy the code (only) from the patch file and pasted it into my webform.module file.
Comment #55
djalloway CreditAttribution: djalloway commentedAmir,
The patch also contains a few additional files that need to be created, make sure you get those created and placed where the Patch file has them located at. (webform/views/*)
Regardless though, the easiest way is just to apply the patch directly via a command line CVS utility, like so.
1.) Copy the patch to the Webform module directory.
2.) From the Webform module directory execute
patch -p0 < webform-273837-50.patch
You'll need a command line cvs patch utility for this to work. (http://gnuwin32.sourceforge.net/packages/patch.htm)
This should apply the patch exactly as it is intended and save you a lot of error from copying and pasting everything in.
Comment #56
djalloway CreditAttribution: djalloway commentedIn reference to #53.
Here is a patch with a new Node field Webform form body which outputs the entire rendered Webform node output.
Once again, this is part of the process of exploring every possibly for getting more Webform data available via Views.
Comment #57
cdale CreditAttribution: cdale commentedI've attached some code that at a high level does what I mentioned in #37.
THIS IS NOT A PATCH! DO NOT TRY AN APPLY IT TO WEBFORM, IT WILL NOT WORK!
Now that that's out of the way... This is a proof of concept, and I've taken it right out of a project I'm working on that has the same logical database structure as webform, but it should give someone a base to work off. The code is pretty well commented. I don't have time to convert this into a proper patch for webform, or write the necessary field handlers, and the approach I've taken is by no means orthodox. Use at your own peril.
Having said that, I'm happy to provide feedback and reasons for why I implemented things the way I did.
I should also note, that I've gone over this code before uploading it and removed a bit of stuff that would have most likely just confused people more, as the logic for it is elsewhere in the module. I've put in some hints prefixed with 'WEBFORM VIEWERS' where I have done something like this, or the logic might need to be subtly different for webform. I also added in some of the webform stuff for hook_views_data(). I think I've also forgotten some code in hook_schema, and node_delete that handles keeping the schema consistent. I can upload that later if required.
Comment #58
iNade CreditAttribution: iNade commentedThanks djalloway, I patched the file with cygwin, uploaded them to webform directory, created "views" folder with the new files...
But i had one error, something with the "header"... and when i try to create a view, blank page.
warning: Cannot modify header information - headers already sent by (output started at /home1/MYSITE/public_html/modules/webform/views/webform.views.inc:1) in /home1/MYSITE/public_html/includes/common.inc on line 141.
Last drupal 6.x and last webform.
Comment #59
cdale CreditAttribution: cdale commentedLooks like the UTF BOM snuck back in. :)
Comment #60
Amir Simantov CreditAttribution: Amir Simantov commented#djalloway in reference to #52
The patch did the job - thanks.
There are some issues which I have with it, though:
1. After applying the patch, when viewing a view in IE (I use IE7) then all page is aligned to the edge instead of in the middle.
2. Using the "submission count" option for a field does not give all the regular configuring options, such as changing the exact text. Is this possible to add?
Thanks once again!
Comment #61
djalloway CreditAttribution: djalloway commented@Charly #58.
Let me re-post the patch file without the UTF BOM first, then download it again, re apply the patch and we'll go from there.
@cdale #59.
I rolled the last patch on a different computer, damn my editor and it's configuration options!
@Amir #60.
Nothing added affects anything style related, that is all Views handled, the patch just supplies the data, can you confirm if the same behavior exists before applying the patch and if it is the patch directly affecting this?
What kind of options do you think would be needed for the Submission Count field? I can work on getting these in if you can help me brainstorm what might be needed, you mentioed being able to change the text, are you referring to the Label or the actual # count being outputted?
Comment #62
djalloway CreditAttribution: djalloway commentedRemoved the UTF BOM from the patch files.
Comment #63
Amir Simantov CreditAttribution: Amir Simantov commented@djalloway #61
1
Hi and thanks. The phenomenon did not occur before applying the patch. Will it be safe to remove the patch in order to check this? Won't it break something? If yes, how to do it?
2
The option I would like most for the submission count field is to be able to rewrite the label with the number as a token. So, instead of, saying "5" (as a link), I can make: "5 submissions".
Thanks!
Comment #64
nelslynn CreditAttribution: nelslynn commentedSubs
Comment #65
Summit CreditAttribution: Summit commentedSubscribing, greetings, Martijn
Comment #66
djalloway CreditAttribution: djalloway commentedless Subs, more Patch!
@Amir
I'll have what we discussed out in the next day or two, to much going on last weekend to focus on this.
Comment #67
iNade CreditAttribution: iNade commentedSub.
Comment #68
Amir Simantov CreditAttribution: Amir Simantov commented@djalloway #66
You are more that helpful, I appreciate it.
Comment #69
djalloway CreditAttribution: djalloway commented**Changes**
Comment #70
Amir Simantov CreditAttribution: Amir Simantov commentedRegarding patch in #69 (what a number...)
Do I have to un-patch the previous patch (in any way) or should I just apply this patch and it will delete the previous one?
Thanks once again...
Comment #71
djalloway CreditAttribution: djalloway commentedIf you patch over any of the previous patches that I've posted it will duplicate all the code, so you definitely do not want to do that.
What you could do, though, is patch a clean copy of the Webform module then copy the "/webform/views/" folder over your existing installations "/webform/views/" folder.
Comment #72
Amir Simantov CreditAttribution: Amir Simantov commentedHi djalloway,
Thanks for the explanation, but unfortunately, this cannot be done in my case. My code is customized (for good reasons, it is not just branching). So, I cannot really re-install the module. Or could I? Is un-checking the webform module under admin/build/modules, save it, and then checking it back and saving will do the trick?
Thanks for you continuous help!
Comment #73
djalloway CreditAttribution: djalloway commentedHere is what you can do.
**Assuming you've already patched your current installation already at least once.**
This won't affect any of the custom code that you have and will give you the latest changes.
*Depending on what revision of the patch you used originally, there have been some serious modifications to a few of the Webform submission fields in Views, so I am not sure if you are currently using any Views of the Webform submission type, but if you are, this may break them and you may have to recreate them.*
Comment #74
djalloway CreditAttribution: djalloway commentedLet's get some fresh eyes on this.
It's at a milestone now, and is pretty useful with it's current functionality.
Comment #75
zapscribbles CreditAttribution: zapscribbles commentedSubscribe
Comment #76
Amir Simantov CreditAttribution: Amir Simantov commented@#73
Will get to it. Thanks!
Comment #77
pebosi CreditAttribution: pebosi commentedHi,
i did a small review and cant find any errors. basic views implementation is working for me with 6.dev and patch 69.
regards
Comment #78
djalloway CreditAttribution: djalloway commentedChapter 2
After a short break, I'm looking at going further with this patch.
The next leg of this adventure will appear as a new Views type called Webform submitted data.
As opposed to the current Webform submissions Views type previously worked on.
The reason for the separation of Views types is due to the huge differences and approach in logic and programming, it will also allow for a more efficient community effort that won't encroach on any previous work done and leave this leg of development in an area all to itself.
**Edit**
There is no guarantee that this part will even happen.
As quicksketch stated very early in this thread
It's one thing to integrate Submission summary data into Views (which we've just completed),
It's something else entirely to deal on a Component / Data level within Webform.
The only logical outcome I can see is a "Views" variation of the already existing "Table" view on the Webform Results page, limited of course to a per-Webform basis, still it's not looking very practical.
Comment #79
attiks CreditAttribution: attiks commentedsubscribing
Comment #80
djalloway CreditAttribution: djalloway commentedAt the moment I am trying to decide on the approach, here is what I have so far.
I really really really would like some thoughts on this approach, from what I can tell, it is the only viable way to remain within the operational pattern of Views and Webform and still accomplish this task.
Comment #81
attiks CreditAttribution: attiks commentedI like the approach, but I have a request: we have multi language webforms, they are identical (same components, same names, different labels) but the nid's are different, so (if possible) convert the dropdown into a multi select list, so I can aggregate the results off all languages into one view.
Comment #82
cdale CreditAttribution: cdale commented@djalloway, that is quite similar to the approach I offered up in #57, however I think I like your idea better, as I use a lot of extra tracking to track which node the view is against, but perhaps using a relationship, it might work. You've got me thinking now. :)
The only difficult thing I came up against in the end, that I still have not solved, is views exporting. Technically, the view is tied to the node once you do this, so it can't just be exported and expected to work. My best ideas at the moment, are to either include an option via the node_export module to include the view, or offer up some flag on import to re-select the node the view is for. Thoughts?
@attiks That sounds like something that would be best handled by a followup to the multilingual patch #245424: Make Webform multilingual (i18n) aware through contributed modules, although with djalloway's idea to base the selected node off the relationship, it might be possible. There would probably need to be a proof of concept or something for it though.
Comment #83
djalloway CreditAttribution: djalloway commentedThis is more of a request for help with the Views API.
An Example is this.
All Profile Fields are looped over and Field Definitions created in the
hook_views_data()
function.That is great if you want ALL the fields listed as available Views Fields.
I want field definitions create in a similar way for Webform Components but ONLY components that match the Node ID selected in a prior defined Relationship.
Unfortuantly I don't have this data (the Node ID) available to me in the Field Definition declaration in the
hook_views_data()
call.Comment #84
cdale CreditAttribution: cdale commentedWhy not create the field listings for all nodes in the
hook_views_data()
call. I think another good idea would be to add a "views enabled" option to each webform node so you only create the fields for webforms that might be used in views.So that's the first step, getting all the fields in. But what would we join them too? Perhaps some sort of "magic" join table that is declared by the relationship? And then when you define the relationship, you provide an option for which webform node, and then the "magic" table knows which "views data definition" to join onto?
I'm not sure if what I'm saying makes much sense, just brain dumping here.
I do know for sure that it would be a bad idea to try and create the field definitions on the fly. That just sounds plain dangerous. Views is not designed for that use case. It selects data from tables, and every field in a view needs to have a 'column' in the result set.
I'm going to have a dig into this over the next few days and see what I can work out. I think it should be mostly possible though, just not sure how clean it will be.
Ideally, each webform view when created will have its own table with just the columns the view needs. This would be purely for performance reasons however, and should most likely only be in a followup patch.
Comment #85
cdale CreditAttribution: cdale commentedOk, so I thought about this a little bit more, haven't tested anything yet, but here's my thoughts so far.
In my mind, the biggest problem is not getting the components into views, but rather showing the right fields for a relationship to a particular node. Filtering out the correct data is going to be easy, as we can just override
query()
on the relationship handler. Getting all the components across all webform nodes is again, going to be easy, it's just a small extension over what is currently there. The difficulty, clearly, is reducing the components shown as being available to views.I can think of a few ways to approach this problem:
form_alter()
on the views form that displays the field options, and dynamically filter out the ones we don't want. I did this already in #57, so I know this can work, but it does feel like a bit of a hack.$views_data
correctly, views will do 90% of the work for us.form_alter()
option. Instead of defining the fields in$views_data
, we don't define them at all, and instead dynamically populate the options as the forms are queried. To me, this seems very dangerous. Also, I'm not sure how this would affect any validation that views would run itself. I'd imagine it might.I think going with number 2 might be the best approach. Thoughts?
Comment #86
djalloway CreditAttribution: djalloway commentedI'll vote for #2 as well, but here is an issue that I'm still not clear on.
Very very true, but here is the problem with the Webform Components table.
It contains NID and CID as references to pull data, it's structure requires that you MUST pass in an NID to get a unique set of CID's back.
The issue with selecting all the Components at any point in the process is that you get overlapping NID and CID's unless you pull using a specific NID.
Which you can't do if you define all Components as Fields in the Field Definitions, so you get overlap and some weird behavior in Views.
I have a "partial" implementation working right now where I actually am getting Data back from Webform components but it's very very very flaky partially due to this issue.
Comment #87
djalloway CreditAttribution: djalloway commentedPractice Code
With regard to my previous post.
A solution to the component problem could be to generate "Alias" View tables for each webform on the system, and have each component as a field within that Alias table.
Now, basically what you have are a number of Views Alias table available for Relationships, Joining or whatever.
This is all just theory, although I do have it somewhat working locally.
My main problem is lack of in-depth knowledge of some of the more advanced Views API code.
Is what I've suggest above even possible as Views Alias tables? Help.
Comment #88
cdale CreditAttribution: cdale commentedYes. It is exactly what I would suggest doing, and what I (very poorly) tried to explain in previous posts. I think that should be totally possible. As for the viewsAPI, I usually just dig around in the views code to find how I can hook into something that I want to do. :)
Comment #89
djalloway CreditAttribution: djalloway commentedglad to hear that I interrupted what you were saying correctly, you were right on the money.
now to dig around and find some deeper Views API code to learn from and try to implement this, oh boy.
for the Alias tables to make 'sense' to views it seems we're going to have to have a handler for each field and each handler will have to heavily modify the "query" construct to explain how each "alias" connects back to retrieve it's data.
otherwise Views won't be able to assemble our aliases in it's query.
given... all these are just assumptions... time to dig.
Comment #90
cdale CreditAttribution: cdale commentedYou might want to take a look at the CCK multiple field handler when grouping fields, or, in the code, when the query is "deffered" What they do there, is simply let the query get the nid/vid's they want, then they actually run a query in the pre_render() method to get the data they want, and then render it in render(). Might be something you can use? Although, that will break any sorting capabilities all together, or if not the sorting, then at least the "paging" options.
If you implement it similar to how the profile views integration is done, then sorting will be slow, but limits will work, if you do it the way CCK handles grouping multiple field data, then you loose both the sorting and the limits I think.
Ideally, we should look at de-normalizing the database and creating a special table for each view, that has a column for each field and sort handlers used in the view. I know people think database de-normalisation is a cardinal sin, but I feel that there are uses, and high performance is a very good reason for doing it.
I'm not going to go into much detail about it here, but there is a good article about it http://www.softwareprojects.com/resources/programming/t-database-perform...
Anyway, I did exactly that in my code in #57. Might be something worth trying if performance is going to be a problem. It will also simplify all the queries, as you'll be selecting from a single normalized table for the view. (Notice the table is normalized, not the database. :)).
Comment #91
djalloway CreditAttribution: djalloway commentedPhase 1 Final Patch
I've gone over all of my code for the first phase of the Webform + Views integration patch.
This patch implements integration with top-level submission data from the
webform_submissions
table.Latest changes include:
hook_views_data_alter()
hook.Overall functionality provided by this patch:
I would like everyone who has participated in this Issue to apply this patch, test and review each of the features listed above.
Upon completion we can closeout this phase of Views + Webform integration and move on to what comes next.
Comment #92
quicksketchNice! I was rerolling the same patch but looks like you got all the changes. Let's just make sure we remove all the trailing white-space before committing (an empty line should not contain any spaces). djalloway, I think this is ready to go. Want to make the first commit?
Comment #93
djalloway CreditAttribution: djalloway commentedYou bet.
You'll have to point me in the right direction this first time around, after that I should be good to go.
Most of all this is a first for me.
Comment #94
djalloway CreditAttribution: djalloway commentedComment #95
djalloway CreditAttribution: djalloway commentedAttached are some usage screen shots of this functionality in action.
This patch can be found in 6.x-3.x-dev.
Enjoy.
Comment #96
marcvangendDan, thanks for all your time and efforts to make this work. Two questions I hope you have the answer to:
- Now that this is committed to the 3.x branch, does that mean that we can expect a 3.x beta version in the near future?
- If I want to start using views integration today, can I apply the patch from #91 to the latest 2.x version, or is that unstable/untested?
Comment #97
quicksketchI doubt a 3.x beta will be out very soon, though I'd like to avoid huge gaps between the 2.x and 3.x versions. At present through the 3.x version is exactly the 2.x version except for this single patch, but it's unlikely to stay that way for long.
Hm, neither approach is very suitable (applying the patch or using the 3.x branch) because it's likely that the views integration has bugs in it (these things inevitably happen) and the bugs will only be fixed in subsequent patches. I think I'd lean toward trying 3.x out, but be very cautious when updating the module, as it will likely be unstable at points.
Comment #98
marcvangendThanks Nate for the quick answers. I guess the least I can do is install the current 3.x-dev in a test site, and report all errors that I encounter... Then I can always decide later on if it feels stable enough to use in one way or the other.
Comment #99
jabraben CreditAttribution: jabraben commentedSubscribing.
Comment #100
z33k3r CreditAttribution: z33k3r commentedSubscribing: Is there any progress on Views integration? This would make my life 150% easier if we had this type of integration available!
Comment #101
djalloway CreditAttribution: djalloway commentedz33k3r, refer to comment #95.
This patch, at least how far it's come, can be found in the 3.x-dev branch of Webform.
Further / deeper development will be started under a new issue when the time comes.
Comment #102
z33k3r CreditAttribution: z33k3r commentedGotcha. Do I need to fully remove the current release before uploading the dev branch? ...or is it compatible to just upload it?
Comment #103
djalloway CreditAttribution: djalloway commentedTechnically... because it's a different release branch, I would remove the old one before uploading the new.
Comment #104
z33k3r CreditAttribution: z33k3r commentedAre tables lost if I, for instance, delete the folder, upload the dev branch and then run update.php?
Comment #105
djalloway CreditAttribution: djalloway commentedno, you should be fine.
Comment #106
matangi CreditAttribution: matangi commentedtested webform version 3.dev and until now I didn't encounter problems.
Just a question, I am looking for a block with the latest webform submissions.
Do you recommend to wait for the further development or is it better to create an individual sql-statement to call the values direct form the database?
It would be very kind if you have a hint for me and maybe even other like to have a block like that.
Katasun
Comment #107
Summit CreditAttribution: Summit commentedYes please for block code.
greetings, Martijn
Comment #108
djalloway CreditAttribution: djalloway commentedI would not recommend using 3.x-dev release on a production site, it is still in it's infancy and radically changing every week.
If you want, I don't see a problem with you applying the patch from Comment #91 to your existing 6.x-2.7 release.
It's been tested and works great, and there will not be much behavior change to that patch specifically come future 3.x releases, so you should have minimal impact and be relatively safe.
Comment #110
eff_shaped CreditAttribution: eff_shaped commentedI keep getting referred to this thread, while looking for a way to alter the appearance of webform-results page.
(The # column, for example, is not really useful, when checking on a form's results; I'd like to hide it.)
Seems like a lot of work went on, but I can't really understand what outcome there has been from this issue.
Can someone summarise for the non-tech amongst us?
Views not integrated... or are they?
Comment #111
djalloway CreditAttribution: djalloway commentedViews is integrated into Webform in the 3.x release.
Yes, using Views you can write your own "Results" page for Webform submissions.
The only part of Webform that is not integrated into Views yet are the webform components.
So at the moment you are limited in integration to webform submission data only.
If you look up at Comment #95 you'll some screen shots I posted where I use this functionality to alter my Webform Results pages.
The only issue here is that Webform 3.x is still in heavy development and will not be production ready quite some time.
Comment #112
eff_shaped CreditAttribution: eff_shaped commentedthanks djalloway, I'll check that out.
Comment #113
goldkey266 CreditAttribution: goldkey266 commentedCan someone help me with the patch? I installed webform 2.7 and views 2.6 then patched with the patch from submission 91
no matter what I did I can't get the new Webform submission type Views or the new user and node fields.
am I missing something?
Comment #114
djalloway CreditAttribution: djalloway commentedThe new Webform Submission base type for Views supplies only the basic Webform submission table data.
To get additional data, such as, User and Node information, you have to use add a "Relationship" to your view and relate to the Node and User tables for the additional fields to appear for use.
Comment #115
kwon CreditAttribution: kwon commentedI am a new to Drupal and am trying to get this patch to work. I am hoping someone can help me. I am using webform v2.7 and views 2.6. I installed the patch. That seemed to work fine. Now I am trying to use it. From reading this long string of comments, it looks like I need to check a checkbox to allow make my webform to be views enabled. Once I do that, I should be able to see webform submissions data from views in the fields menu. Is that correct?
Where is the checkbox that makes my webform views enabled? I looked under content management -> webforms -> edit and cannot find anything.
Thanks for any help.
Comment #116
marcvangendPlease be careful with changing the status of issues. You're changing the properties of the entire issue, it's not just about your post. I'm setting it back to what this (closed) issue is about: a new feature, implemented in the 6.x-3.x-dev version by adding new code.
Comment #117
kwon CreditAttribution: kwon commentedSorry about changing the item status. I will not change that next time.
Comment #118
djalloway CreditAttribution: djalloway commented@kwon
The details in comment #91 pretty much go over the details of what this patch does.
I think what you are describing may be what we are planning on working on for Phase 2 of the Views + Webform integration.
Currently though, that functionality does not exist.
You can think of Phase 1 integration as an Views enhanced Submission Results screen, there is no direct access via Views to the actual Submission Component data... yet.
Comment #119
VladoMire CreditAttribution: VladoMire commentedThanks, nice job!
But I have another problem to get viewing list of submissions for some role.
How to access the variables from body submission (in views)?
I need to get the results of submissions into account not only their own but also those in which the data (with another cid) field of table webform_submitted_data contains the mail ito equal to mail of logged user who is viewing the results of submissions.
Comment #120
excaliburst CreditAttribution: excaliburst commentedSubscribing.
*******
What I want really is a quick and clean way to make forms for my Drupal site. It seems Webform is the only way to do this at the moment. I'm not a coder so I have to rely on modules for these things.
Is there no other way to create clean looking forms without all the description field, and the different fieldsets at the bottom??? I just want clean looking forms, made quickly.
Then if I select Webform I run into the lack of Views2 integration.
Thanks for your efforts.
BR
Morten E
Comment #121
ramandeep.kaur CreditAttribution: ramandeep.kaur commentedI need to have a dropdown where i have to populate data from a view (of all the OG's say). Is this possible....??
Comment #122
marcvangend@ramandeep.kaur: that's a different thread in the issue queue: #151603: Can I put options in a select field from a database query?
Comment #123
rzelnik CreditAttribution: rzelnik commentedsubscribe
Comment #124
rzelnik CreditAttribution: rzelnik commentedI have installed the 3.x-dev. I can create a View with webform submission View/Edit/Delete links, date & IP... This works well, but is it possible to display the submissions' contents directly in the view?
Comment #125
djalloway CreditAttribution: djalloway commented@rzelnik
Not at the moment, no.
We are welcoming any progress in this area though, but branching off to that level of data within views is proving to be very cumbersome.
Comment #126
jtchan CreditAttribution: jtchan commentedsubscribe
Comment #127
amariotti CreditAttribution: amariotti commentedSubscribing.
Comment #128
diederik_2mpact CreditAttribution: diederik_2mpact commentedSubscribing.
Comment #129
ianchan CreditAttribution: ianchan commentedsubscribe
Comment #130
ldweeks CreditAttribution: ldweeks commentedsubscribing
Comment #131
cameronp CreditAttribution: cameronp commented@djalloway, Just after some quick guidance here. Downloaded the latest 3.dev version branch, and can see the webform submission view type. However I cannot add any relationships at all (Well it doesnt give me any options, there is a relationship avail for signup but thats it)
Just wondering if I'm doing something wrong. Also I dont see a list of submissions like you have under the my account page also..
thanks,
Cameron
Comment #132
cameronp CreditAttribution: cameronp commenteddoh- i hadnt saved any fields yet. Sorry about that it works fine.
Comment #133
djalloway CreditAttribution: djalloway commentedglad you got it working!
we welcome any additional features and/or fixes to this, any input would be appreciated.
Comment #134
wolftmc CreditAttribution: wolftmc commentedsubscribing
Comment #135
dtarc CreditAttribution: dtarc commentedHi,
We are currently costing out a large project. The project will depend on views integration of webform components. I am looking through the 3.x-dev code to see how close this is.
Is there a roadmap or specific issue where the integration of the components is being discussed? If the project looks feasible we may be able to put a month worth of development time towards getting this feature working properly.
Thanks
Comment #136
djalloway CreditAttribution: djalloway commented@dtarc
Currently we've only been able to integrate the Submission table with views.
The data structure of Webform does not allow us to integrate the actual data of the submissions very easily.
And there are a number of performance implications for this level of integration as well.
Regardless I have not looked at this for many months now.
I do plan on getting back into it soon once some of my larger projects have cleared out.
Any effort on this front is welcomed.
Comment #137
joachim CreditAttribution: joachim commentedSubscribe.
I am working on a way to use a webform within a signup form: #29568: Flexible number and type of fields; and since signup data is available to views it'll make sense for this system to have the webform data in the views too.
re: #136, submissions data.
Profile module has the same problem in that its data storage is also one big long table of every field one after the other. For single valued fields, just alias the table. For things like checkboxes, write a loader handler like taxonomy does to get multiple terms as a single field.
I haven't time to devote to this right now, but this might help someone else on the right track... :)
@djalloway is this issue meant to be closed? there's #520404: How to show submission in a view too btw.
Comment #138
quicksketchI opened #680386: Views integration for the webform_submitted_data table for Views integration with the actual submissions.
Comment #139
roknrod12 CreditAttribution: roknrod12 commentedI've installed this addon module. I'd like to get a view similar to the screenshots djalloway posted on #95, but I can't seem to find any of my form fields to display. Can anyone tell me what I'm overlooking? The only fields available are:
Webform submissions: Edit link
Webform submissions: Sid Sid
Webform submissions: Submitted Submitted
Webform submissions: View link
I'd just like to see one of the unique fields filled in by the user to be able to quickly tell what form results I need to dive into, rather than the id.
Comment #140
djalloway CreditAttribution: djalloway commentedroknrod12,
The submission fields you've listed and any other fields made available by adding Views Relationships (like Node title.. etc) are the only ones that you can use at the moment.
This integration does not yet include access to the actual Webform Component data that you may have in your Webform.
You'll need to keep track of the following issue for information on enhancing this integration to include Webform Submission Data
#680386: Views integration for the webform_submitted_data table
Cheers.
Comment #141
roknrod12 CreditAttribution: roknrod12 commentedThanks for the quick response - and great job on your first project!
Comment #142
Rupert3 CreditAttribution: Rupert3 commentedI'm a bit confused... is there a patch to get this working with the Drupal 6 and Views 2??? What do I do?
Comment #143
djalloway CreditAttribution: djalloway commentedRupert3,
This patch is now a part of the Webform 3.x branch.
We do not recommend it for production use at this time, but you are more than welcome to download and try it out.
The other options which involve the currently stable branch of Webform 2.x, which is what you are probably using, are to download the 2.x version of the patch from this issue and apply it yourself, or try using the http://drupal.org/project/webform_views module.
Cheers.
Comment #144
meshwetaHello djalloway,
I have used your module "webform_views", It is amazing. But can we add webform fields into it? If we can then it will be great.
Comment #145
djalloway CreditAttribution: djalloway commentedThat module has been discontinued due to the release of Webfrom 3.x
Webform Field support is out of grasp at the moment due to performance and data storage complexities.
If there is any movement in this direction, you'll see it happen at over at #680386: Views integration for the webform_submitted_data table
Comment #146
djalloway CreditAttribution: djalloway commentedI swear, Drupal needs a confirmation on issue status change.
Comment #147
meshwetaHello djalloway
Thanks for such quick reply. I have tried to write a function with mysql query, But I am unable to take dynamic fields in view.
Comment #148
marcvangendmeshweta, please start a new issue or forum topic for support request. Setting this to closed, like it was before #144.
Comment #149
meshwetaI found one module for webform reports, we can easily show the results as we want without creating view. The module is http://drupal.org/project/webform_report
Thank you to all
Comment #150
Itangalo CreditAttribution: Itangalo commentedThere is now a module called Webform MySQL Views (http://drupal.org/project/webform_mysql_views), which can be tricked into exposing Webform submission data in Views.
Here's a screencast to show you how: http://nodeone.se/blogg/finally-webform-submission-data-in-views
Comment #151
joachim CreditAttribution: joachim commentedFrom that project page:
And MySQL Views are pretty evil :/
Comment #152
Danny EnglanderRE, #150:
It's important to note that you also need the Data module for this to work which is mentioned in the NodeOne's screencast. http://drupal.org/project/data
Comment #153
paskainos CreditAttribution: paskainos commentedsubscribing
Comment #154
lsolesen CreditAttribution: lsolesen commented+1
Comment #155
hendrohwibowo CreditAttribution: hendrohwibowo commented+1
Comment #156
thomasmurphy CreditAttribution: thomasmurphy commentedI've ended up on this page a few times and thought I'd post this because I found it quite useful. http://archive.org/details/DisplayWebformSubmissionDataInViews
Views is a bit deceptive having a default setting for displaying webform data, without allowing the display of any submissions!
Comment #157
vrwired CreditAttribution: vrwired commentedright that video is useful tutorial - here's the same one with better clarity: http://vimeo.com/18701843