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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

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

alanburke’s picture

Version: 5.x-2.0 » 6.x-2.x-dev

Theoretically possible with Views 2 in Drupal 6.
Bumping version.

quicksketch’s picture

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

quicksketch’s picture

Title: Displaying webform fields in Views » Views Integration for Webform
shanefjordan’s picture

I 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

marie_t’s picture

Subscribing, 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?

quicksketch’s picture

EclipseGC (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.

mrfelton’s picture

interesting idea and I'm all for it.

Chris Charlton’s picture

Subscribing.

3CWebDev’s picture

sub

matt2000’s picture

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

greg@beargroup.com’s picture

As 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

asak’s picture

Subscribing! ;)

wuf31’s picture

Subscribing! :)

bwoods’s picture

Subscribing

Jim Ruby’s picture

subscribing

k3vin’s picture

subscribing

latte’s picture

This will be a great plugin.

gausarts’s picture

wow it's so exciting. allow me to subscribe, thanks

KrisBulman’s picture

any movement on this?

Anonymous’s picture

subscribing..

I'd imagine views could be used to generate a random selection/shortlist from all submissions.

InternetDevels’s picture

subs

Panda_N_Shark’s picture

subscribing.

grey_’s picture

subscribing

Jim Ruby’s picture

subscribing - any progress? Thank you. Looking forward to this.

sunset_bill’s picture

This 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()

function webform_perm() {
  return array('create webforms', 'edit own webforms', 'edit webforms', 'access webform results', 'access simple results', 'clear webform results', 'access own webform submissions', 'edit own webform submissions', 'edit webform submissions', 'use PHP for additional processing');
}

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.

  // Node webform results.
  $items['node/%webform_menu/webform-results'] = array(
    'title' => 'Results',
    'page callback' => 'webform_results_analysis',
    'page arguments' => array(1, FALSE, '50'),
    'access callback' => 'webform_results_access',
    'access arguments' => array(1, 'access simple results'),
    'file' => 'webform_report.inc',
    'weight' => 2,
    'type' => MENU_LOCAL_TASK,
  );
.
.
.
  $items['node/%webform_menu/webform-results/submissions'] = array(
    'title' => 'Submissions',
    'page callback' => 'webform_results_submissions',
    'page arguments' => array(1, FALSE, '50'),
    'access callback' => 'webform_results_access',
    'access arguments' => array(1, 'access webform results'),
    'file' => 'webform_report.inc',
    'weight' => 4,
    'type' => MENU_LOCAL_TASK,
  );
  $items['node/%webform_menu/webform-results/analysis'] = array(
    'title' => 'Analysis',
    'page callback' => 'webform_results_analysis',
    'page arguments' => array(1),
    'access callback' => 'webform_results_access',
    'access arguments' => array(1, 'access simple results'),
    'file' => 'webform_report.inc',
    'weight' => 5,
    'type' => MENU_DEFAULT_LOCAL_TASK,
  );

Then, give authenticated and even anonymous users 'access simple results' permission.

Hope that helps a few at least.

salud,
Bill

taxicab221’s picture

subscribing

djalloway’s picture

Status: Active » Needs review
FileSize
4.93 KB

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

  • Node
  • Node Revision
  • User

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!

djalloway’s picture

Ok, yea, the patch file I submitted does not apply correctly.
I'll take another swing at it and re-post it.

djalloway’s picture

FileSize
5.55 KB

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

  • Modify webform/webform.module
  • Add webform/views/webform.views.inc
  • Add webform/views/webform_handler_field_submission_link.inc

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.

quicksketch’s picture

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

djalloway’s picture

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

djalloway’s picture

Version: 6.x-2.x-dev » 6.x-2.6
Status: Needs review » Needs work
FileSize
9.28 KB

I think making submissions a base table would make a lot of sense in this situation.

Done.

Obviously we'll need to make some special handlers for display of several fields.

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?

quicksketch’s picture

I rolled this patch against a clean copy of Webform, is this the correct way to re-post a patch?

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

+  function access() {
+    return user_access('edit webform submissions');
+  }

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

  $data['webform_submissions']['delete_submission'] = array(
    'field' => array(
      'title' => t('Delete link'),
      'help' => t('Provide a simple link to delete the submission.'),
      'handler' => 'webform_handler_field_submission_link_delete',
      'access callback' => 'webform_submission_access',
      'access arguments' => array($uhhh_not_sure, $if_you_have_vars_you_need),
    ),
  );

Then remove your access() method and fallback to the Views default one.

djalloway’s picture

FileSize
10.32 KB

Key notes.

  • Node & User relationships.
  • Updated access checks

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.

djalloway’s picture

It looks like the typical way to do this is to set an "access callback" on the field itself in hook_views_data().

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

cdale’s picture

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

cdale’s picture

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

djalloway’s picture

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

djalloway’s picture

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.

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

cdale’s picture

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

djalloway’s picture

FileSize
11.8 KB

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

cdale’s picture

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

djalloway’s picture

FileSize
11.7 KB

Without the BOM.

mukatira’s picture

This 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

cdale’s picture

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

cdale’s picture

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


/**
 * Parent field handler to present a link (view, edit, delete?) to the user.
 */
class webform_handler_field_submission_link extends views_handler_field {
  var $link_type;

  function construct() {
    // We need to set this property before calling the construct() chain
    // as we use it in the option_definintion() call.
    $this->link_type = $this->definition['link_type'];

    parent::construct();
    $this->additional_fields['sid'] = 'sid';
    $this->additional_fields['nid'] = 'nid';
    $this->additional_fields['uid'] = 'uid';
  }
  
  function allow_advanced_render() {
    return FALSE;
  }
  
  function option_definition() {
    $options = parent::option_definition();
    $options['label'] = array('default' => '', 'translatable' => TRUE);
    $options['text'] = array('default' => $this->link_type, 'translatable' => TRUE);
    return $options;
  }
  
  function options_form(&$form, &$form_state) {
    parent::options_form($form, $form_state);
    
    $form['text'] = array(
      '#type' => 'textfield',
      '#title' => t('Text to display'),
      '#default_value' => $this->options['text'],
    );
  }
  
  function query() {
    $this->ensure_my_table();
    $this->add_additional_fields();
  }
  
  function render($values) {
    switch ($this->link_type) {
      case 'delete':
        $text = !empty($this->options['text']) ? $this->options['text'] : t('delete');
        break;
      case 'edit':
        $text = !empty($this->options['text']) ? $this->options['text'] : t(edit);
        break;
      case 'view':
        $text = !empty($this->options['text']) ? $this->options['text'] : t('view');
        break;
    }

    $submission = new stdClass();
    $submission->sid = $values->{$this->aliases['sid']};
    $submission->nid = $values->{$this->aliases['nid']};
    $submission->uid = $values->{$this->aliases['uid']};

    // we do our access check here because this is the only location
    //  where the variables are available that we need.
    if (!webform_submission_access($submission->nid, $submission, 'delete')) {
      return;
    }
    
    return l($text, "node/$submission->nid/submission/$submission->sid/". $this->link_type, array('query' => drupal_get_destination()));
  }
}

2. Change the link definitions in hook_views_data() to include the link_type option on the field:


 // view link
  $data['webform_submissions']['view_submission'] = array(
    'field' => array(
      'title' => t('View link'),
      'help' => t('Provide a simple link to view the submission.'),
      'handler' => 'webform_handler_field_submission_link_view',
      'link_type' => 'view',
    ),
  );
  
  // edit link
  $data['webform_submissions']['edit_submission'] = array(
    'field' => array(
      'title' => t('Edit link'),
      'help' => t('Provide a simple link to edit the submission.'),
      'handler' => 'webform_handler_field_submission_link_edit',
      'link_type' => 'edit',
    ),
  );
  
  // delete link
  $data['webform_submissions']['delete_submission'] = array(
    'field' => array(
      'title' => t('Delete link'),
      'help' => t('Provide a simple link to delete the submission.'),
      'handler' => 'webform_handler_field_submission_link_delete',
      'link_type' => 'delete',
    ),
  );


3. Delete all the extra edit/delete/view classes that were made.

Amir Simantov’s picture

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

djalloway’s picture

FileSize
8.49 KB

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

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

djalloway’s picture

FileSize
10.57 KB

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?

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

Amir Simantov’s picture

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

djalloway’s picture

Amir Simantov,

I'm going to need a bit more information then that.

  1. What version of Webform did you apply the patch to?
  2. What were you doing when / before you got the error?
  3. Was this a clean install of Drupal? Or is it an existing site with other modules installed?
djalloway’s picture

Preface

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?

Amir Simantov’s picture

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

djalloway’s picture

Amir,

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.

djalloway’s picture

FileSize
12.26 KB

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

cdale’s picture

FileSize
45.39 KB

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

iNade’s picture

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

cdale’s picture

Looks like the UTF BOM snuck back in. :)

Amir Simantov’s picture

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

djalloway’s picture

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

djalloway’s picture

FileSize
12.25 KB

Removed the UTF BOM from the patch files.

Amir Simantov’s picture

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

nelslynn’s picture

Subs

Summit’s picture

Subscribing, greetings, Martijn

djalloway’s picture

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

iNade’s picture

Sub.

Amir Simantov’s picture

@djalloway #66
You are more that helpful, I appreciate it.

djalloway’s picture

FileSize
11.87 KB

**Changes**

  1. Fixed a circular association with Node, Node Revision and User.
  2. Enabled Advanced Options for the Node Field Submission Count.
  3. Enabled Advanced Options for the Node Field Form Body.
Amir Simantov’s picture

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

djalloway’s picture

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

Amir Simantov’s picture

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

djalloway’s picture

Here is what you can do.
**Assuming you've already patched your current installation already at least once.**

  1. Download the latest version of the Webform module to a new/clean location on your computer.
  2. Apply the latest revision of the patch to this clean version of the module.
  3. Delete the existing "/webform/views/" folder from your current/live/production patched installation.
  4. Copy out only the "/webform/views/" folder from the clean directory to your current installation.

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

djalloway’s picture

Status: Needs work » Needs review

Let's get some fresh eyes on this.
It's at a milestone now, and is pretty useful with it's current functionality.

zapscribbles’s picture

Subscribe

Amir Simantov’s picture

@#73
Will get to it. Thanks!

pebosi’s picture

Hi,

i did a small review and cant find any errors. basic views implementation is working for me with 6.dev and patch 69.

regards

djalloway’s picture

Chapter 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

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.

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.

attiks’s picture

subscribing

djalloway’s picture

At the moment I am trying to decide on the approach, here is what I have so far.

I will not create a new Views Base Type for the Webform Submitted Data.
Instead I will create a 'special' relationship on the already existing Views Node Base Type.
This relationship will require you to select a Webform from a drop-down list of all Webforms available on the site.
Upon making a selection, the Node View is now limited to the Nid of the Webform that was chosen.
Then and only then does it populate the Fields List with the necessary Webform Components, granting access via special Handlers to the Webform Submitted Data.

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.

attiks’s picture

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

cdale’s picture

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

djalloway’s picture

This is more of a request for help with the Views API.

How do you define fields in Views only AFTER a value has been established via Relationship?

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.

cdale’s picture

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

cdale’s picture

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

  1. We use a 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.
  2. Define a relationship for each webform node. This seems like it would be the most flexible, and would probably make more sense to views. This way, if we define the $views_data correctly, views will do 90% of the work for us.
  3. We do the reverse of the 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?

djalloway’s picture

I'll vote for #2 as well, but here is an issue that I'm still not clear on.

cdale: It selects data from tables, and every field in a view needs to have a 'column' in the result set.

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.

djalloway’s picture

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

// retrieve all available webforms on the system
// note, that this could be limited to only Webforms who have 'allowed' views access.
$webforms = webform_views_get_webforms();

foreach ($webforms as $webform) {
  // generate a unique alias table name for this webform
  $table_name = 'webform_node_'. $webform->nid;
  $data[$table_name]['table']['group'] = t('Webform: '. $webform->title);

  // retrieve all components for this webform
  $components = webform_views_get_components($webform->nid);
  foreach ($components as $component) {
    // generate a field name for this component from it's form key
    $field_name = $component->form_key;

    // add this field to the alias table for it's webform
    // also, retrieve it's submitted_data as it's value. (still duplicating Profile Fields functionality here)
    $data[$table_name][$field_name] = webform_views_fetch_component($component);
  }
}

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.

cdale’s picture

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

djalloway’s picture

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

cdale’s picture

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

djalloway’s picture

FileSize
12.79 KB

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

  • Utilization of the hook_views_data_alter() hook.
  • Submission count field (per-user).

Overall functionality provided by this patch:

  • For Node type Views
    • Webform body field (allows the display of the actual Webform form in a typical Node view)
    • Submission count field (submissions count per Webform)
  • For User type Views
    • Submission count field (submission count per User)
  • For the new Webform submission type Views
    • Node relationship.
    • User relationship.
    • Submission View link field (w/ access check)
    • Submission Edit link field (w/ access check)
    • Submission Delete link field (w/ access check)
    • Remote Address field
    • Submitted Date field
    • Submission ID field

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.

quicksketch’s picture

Status: Needs review » Reviewed & tested by the community

Nice! 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?

djalloway’s picture

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

djalloway’s picture

Version: 6.x-2.6 »
Assigned: Unassigned » djalloway
Status: Reviewed & tested by the community » Fixed
djalloway’s picture

Attached are some usage screen shots of this functionality in action.
This patch can be found in 6.x-3.x-dev.
Enjoy.

marcvangend’s picture

Dan, 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?

quicksketch’s picture

- 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?

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

- 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?

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.

marcvangend’s picture

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

jabraben’s picture

Subscribing.

z33k3r’s picture

Subscribing: Is there any progress on Views integration? This would make my life 150% easier if we had this type of integration available!

djalloway’s picture

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

z33k3r’s picture

Gotcha. Do I need to fully remove the current release before uploading the dev branch? ...or is it compatible to just upload it?

djalloway’s picture

Technically... because it's a different release branch, I would remove the old one before uploading the new.

z33k3r’s picture

Are tables lost if I, for instance, delete the folder, upload the dev branch and then run update.php?

djalloway’s picture

no, you should be fine.

matangi’s picture

tested 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

Summit’s picture

Yes please for block code.
greetings, Martijn

djalloway’s picture

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

Status: Fixed » Closed (fixed)

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

eff_shaped’s picture

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

djalloway’s picture

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

eff_shaped’s picture

thanks djalloway, I'll check that out.

goldkey266’s picture

Version: » 6.x-2.7

Can 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?

djalloway’s picture

Version: 6.x-2.7 »

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

kwon’s picture

Version: » 6.x-2.7
Component: Code » Documentation
Category: feature » support

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

marcvangend’s picture

Version: 6.x-2.7 »
Component: Documentation » Code
Category: support » feature

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

kwon’s picture

Sorry about changing the item status. I will not change that next time.

djalloway’s picture

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

VladoMire’s picture

Issue tags: +webform

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

excaliburst’s picture

Subscribing.

*******

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

ramandeep.kaur’s picture

I need to have a dropdown where i have to populate data from a view (of all the OG's say). Is this possible....??

marcvangend’s picture

@ramandeep.kaur: that's a different thread in the issue queue: #151603: Can I put options in a select field from a database query?

rzelnik’s picture

subscribe

rzelnik’s picture

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

djalloway’s picture

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

jtchan’s picture

subscribe

amariotti’s picture

Subscribing.

diederik_2mpact’s picture

Subscribing.

ianchan’s picture

subscribe

ldweeks’s picture

subscribing

cameronp’s picture

@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

cameronp’s picture

doh- i hadnt saved any fields yet. Sorry about that it works fine.

djalloway’s picture

Issue tags: -webform

glad you got it working!
we welcome any additional features and/or fixes to this, any input would be appreciated.

wolftmc’s picture

subscribing

dtarc’s picture

Hi,

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

djalloway’s picture

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

joachim’s picture

Subscribe.

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.

quicksketch’s picture

I opened #680386: Views integration for the webform_submitted_data table for Views integration with the actual submissions.

roknrod12’s picture

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

djalloway’s picture

roknrod12,

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.

roknrod12’s picture

Thanks for the quick response - and great job on your first project!

Rupert3’s picture

I'm a bit confused... is there a patch to get this working with the Drupal 6 and Views 2??? What do I do?

djalloway’s picture

Rupert3,

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.

meshweta’s picture

Version: » 6.x-2.x-dev
Category: feature » support
Priority: Normal » Critical
Status: Closed (fixed) » Active

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

djalloway’s picture

Status: Active » Closed (won't fix)

That 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

djalloway’s picture

Category: support » feature
Priority: Critical » Normal
Status: Closed (won't fix) » Fixed

I swear, Drupal needs a confirmation on issue status change.

meshweta’s picture

Status: Fixed » Closed (won't fix)

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

marcvangend’s picture

Status: Closed (won't fix) » Closed (fixed)

meshweta, please start a new issue or forum topic for support request. Setting this to closed, like it was before #144.

meshweta’s picture

Category: feature » task
Priority: Normal » Minor

I 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

Itangalo’s picture

There 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

joachim’s picture

From that project page:

Note: This module does not directly provide Drupal Views module integration for Webform data. It builds MySQL Views, which are something else entirely.

And MySQL Views are pretty evil :/

Danny Englander’s picture

RE, #150:

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

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

paskainos’s picture

subscribing

lsolesen’s picture

+1

hendrohwibowo’s picture

+1

thomasmurphy’s picture

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

vrwired’s picture

right that video is useful tutorial - here's the same one with better clarity: http://vimeo.com/18701843