This module implements a preprocess hook (function webform_civicrm_preprocess_webform_results_submissions) to alter the webform results table and add the name of the CiviCRM contact who submitted the form - many people find this to be a useful feature. It has worked with webform versions through 4.1.

As of Webform 4.2 the results submissions table has been converted to a View. That's nice, but it prevents this module's preprocess hook from injecting CiviCRM contact info into the table.

The proper solution is probably to expose webform_civicrm data to views so it can be added to the View (and ideally add it programmatically to the default view shipped with the Webform module, although this gets a little tricky with handling CiviCRM-enabled vs non-CiviCRM-enabled webforms)

A less proper solution might be to do a similar theme hook targeting that new view, but this seems like it might be dodgy if the view gets modified by the site admin.

Comments

colemanw’s picture

colemanw commented

I don't have experience writing a views handler or time to learn right now. It would be really awesome if someone from the community could step up with a patch.

colemanw’s picture

colemanw commented
Issue summary: View changes
druth’s picture

druth commented

probably not a long term solution but you could try adding this to settings.php:

$conf['webform_table'] = TRUE;

as suggested here: https://www.drupal.org/node/2374721

colemanw’s picture

colemanw commented

Thanks for pointing out this workaround @druth. As I just asked in the comments, do you know if it would be possible for this module to set that variable or is it going to be up to each site admin to manually change their settings.php file?

  • colemanw committed 97771bf on 7.x-4.x 
    Issue #2389537 temporary workaround - disable Views results table...
colemanw’s picture

colemanw commented

Nevermind I figured it out. Ok I have pushed up the temporary fix to disable the view and display results in the old way.
Not a permanent solution by any means. If anyone out there has Views experience your help would be much appreciated!

petednz’s picture

petednz commented
Priority: Normal » Major

any chance this has come back to bite us

a site where i had 7.x-4.9+9-dev (2014-Oct-07) has just stopped putting the name in to the 'user' column in results presumably after the last (security) upgrade for webform.

I upgrade with webform_civicrm to latest ie 4.10 and ran db updates.

But the View continues to show 'anonymous'

/webform-results is definitely showing as a View again.

What do we need to do to the view to make it play nicely. something like - if uid=0 (or regardless) then go join webform_submission to webform_civicrm_submission via the sid and grab us the contact_id for cid1 and then give us the display name instead

and is the missing bit that we need a Views Relationship to join webform_submission to webform_civicrm_submission?

(hope upping the priority is okay but assuming this is happening on all webforms it is kind of a pain)

colemanw’s picture

colemanw commented

Pete, I'm not seeing that problem. In v4.10 of this module I added a hack to set the 'webform_table' variable to true. Visiting the webform tab should trigger this. If something is interfering with this maybe try adding it to settings.php as suggested in comment #3.

petednz’s picture

petednz commented

thx - you comment triggered me to try 'flush caches'

all good now

colemanw’s picture

colemanw commented
Version: 7.x-4.9 » 7.x-4.10
Priority: Major » Normal
Status: Active » Needs work

Ok, so current status is that the workaround works to suppress the view.
Still looking for someone with a little views experience to step up and offer a solution that will work with the new view.

upperholme’s picture

upperholme commented

I have a use case where I really don't need to have the Civi contact listed or linked in my webform results page, and would greatly benefit from being able to use and customise the View.

What's needed to stop webform_civicrm from disabling the Views results table?

upperholme’s picture

upperholme commented

Better yet, given that this issue hasn't moved in two years, what about the idea of enabling an option in the UI so that the admin can control whether to override the Views table?

upperholme’s picture

upperholme commented

Or I guess we just sidestep the default results and use our own Views, but that's a second class solution.

mpaulson’s picture

mpaulson commented
Status: Needs work » Closed (outdated)

This issue was filed against a branch (7.x-4.x) that is no longer supported. We're sorry we did not get to work through it, but once you upgrade to 7.x-5.x and if the issue persists, please feel free to re-open.

jensschuppe’s picture

jensschuppe commented
Version: 7.x-4.10 » 7.x-5.x-dev
Priority: Normal » Major
Status: Closed (outdated) » Active

Unfortunately, this is still an issue, and I'd say it is even Major since this module silently changes (default) configuration during runtime with no chance for the site builder to suppress that.

I see that making CiviCRM component data available to Views is a bigger issue, but disabling the variable just for that purpose globally is not an option. The module should not do that, but instead document that this workaround exists and also that it will have the side-effect of disabling Views usage for webform result tables altogether.

Although the original issue title indicates that this would be a feature request, I'll leave the category at Bug report, since the "solution" introduced a bug.

colemanw’s picture

colemanw commented

@jensschuppe it doesn't look like this issue is every going to get solved for D7, which is approaching EOL. Perhaps though we should move the `variable_set` to the install script instead of runtime code? Or perhaps there's a way to temporarily override the variable only on webform_civicrm results pages and not globally?