Results Not Anonymous

This suddenly started happening to us! It worked a few weeks ago. This is very disturbing. We haven't done any other updates/upgrades.

Marking this as critical. It's not only undescribed (and contrary) behaviour, it's potentially a security breach in unexpected ways.

This may be related to the latest webform. We're on 7.x-4.2+10-dev, and pushed the changes a few weeks ago. Just hadn't looked at the results until now.

It appears as if the webform module now requires views and uses views for displaying the webform submissions (as well as other tables in the admin interface). However, their API remains the same and thus is broken as it does not promise to do what it says.

Use 3.x of webform. I can do nothing if the webform API does not work.

I made a bug report: https://www.drupal.org/node/2451475

Issue resolved in webform queue with options for modifying this module for continued compatibility. See related issue.

Dan, as I mentioned in the other issue, I don't think this does resolve it. The Views integration does not fulfil the promise of the API to retrieve submissions via the hook, and I don't believe that's the best behaviour, or should be expected behaviour either.

You also have the option to disable the new views integration as described in the release notes. The reason I left that in is exactly for situations like this where you might be relying on the old behavior.

That said, I suggest you update the module to adjust the views to your liking, or even obsolete the module, replacing it with instructions for editing the view. Part of the purpose of the views integration was to allow the full flexibility of views in the hopes of avoiding the need for custom code and theming.

The problem is that this functionality isn't always enabled; I'd like to be able to rely on the API to do what it says it'll do, and on any display of the results -- regardless of whether that's through Views, or not -- actually run the hooks. It doesn't matter whether the data display is done via Views or anything else, its behaviour should be _consistent_. That's the problem. I'm sure I could tweak the Views, but any time Webform data is viewed through a View, we can no longer rely on the API's promises. That's a big deal.

The deprecated table function will always be available in the 7.x-4.x branch. Should there be a 7.x-5.x branch, it would be eliminated then, and it is or will soon be eliminated from the 8.x branch.

To share my vision of webforms, I see the direction of reporting, exporting, and analysis as moving to being native views based over time. Right now, the views integration is a bit cobbled together because the webform schema, lack of machine names for webforms or groups of webforms, and the lack of machine names for components make it hard to do more with views. If we can get to the point that webform data can be loaded with pure SQL, then we gain features like better filtering (including exposed filtering) and sorting -- things that just aren't really possible with loading all the submissions into memory.

When you view the webform submissions table, the submissions are not loaded at all. The submissions are loaded (currently) for the webform results table, but only for the data, not for the submission meta data, such as IP address.

I might point out that the API does not promise that submissions are loaded when these tables are displayed. It only promises that the hook will run when the submissions are loaded.

I think the easiest and best thing might be a hook_view_alter. To facilitate this (and as a general improvement), I changed the tag for the built-in webform views from 'default' to 'webform' would help you identify them. #2452771: Use views tag of 'webform' for webform built-in views

I am all for porting UI to views. I love that about the direction of Drupal 8.

Using views, however, while offering API functions that do not do what they say they will do because of the views integration, is where the problem is. I can easily add a message on this module's homepage about incompatibility with the views integration in 4.x and recommend modification of the view itself to port functionality, but the API functions need to be removed if that functionality no longer exists in the API. That is the best option. This module is, for all intents and purposes, obsolete for webform 4.x. There are alternative, more Drupaly ways of getting this functionality.

Actually if you read the API file, it never says that the hook is called for all uses. It says that it is called when submissions are loaded. If you write a view that displays, say, the last log-in date for a user, do you expect hook_user_load to be called?

The change to using views was announced in bold letters in the release notes and a change notice was written. A conf variable was introduced to maintain the deprecated behavior. I have created a tag to facilitate this module's hook_view_alter.

I am happy to entertain all reasonable suggestions to help this module adapt, but loading submissions before displaying the IP address isn't a reasonable suggestion.

I was a BIG fan of this module and the way it worked before. We have used it to do several staffing surveys that needed to be submitted anonymously. Before the update to webform, I was comfortable sending out surveys and telling people their answers were truly anonymous. Now though, I don't know if I can use this module the same way. I HAVE modified the submission view so that it doesn't include the UID and IP, but I know that I can still go back and change that setting, which makes me feel weird about advertising my survey as truly anonymous. I honestly have no knowledge of all this hook_form_alter talk (I'm no programmer!), and I really welcomed the simplicity of this module when I found it.

It would be GREAT to have this sort of functionality baked into the Webform module itself (have the option to strip out the submission details of each submission). In my opinion, it is 100% necessary when building forms for business purposes.

My only other idea would be to restrict submissions to anonymous users, and then create some sort of long string URL that is sent out to staff members to complete. The IP address would still be collected, but at least their usernames wouldn't be. The issue would be that there would be a possibility (though small) that a non-staff member found the survey somehow since it is available to all anonymous users.

@kyleheney -- You always had access to that data as an administrator. You could always have written a view to show it, or looked at the table with something as simple as phpmyadmin. The only difference is that you are no longer blissfully ignorant.

PS. Your mom is the Tooth Fairy. ;)

Edit: Here's an idea. This module could run a cron job which looks for completed submissions or abandoned drafts and sanitizes them every X hours.

Haha re: tooth fairy comment

Would true anonymous submissions ever be something that could be added to the Webform module? It's a feature that would be very beneficial for confidential surveys, etc. If this isn't possible due to limitations (that I don't really fully understand), then I guess that's fine... but if it is possible to add this functionality, I honestly think it would be a welcomed addition to what is already a great module.

I solved it like this:

function hook_webform_submission_presave($node, &$submission) {
    if (intval($submission->nid) !== 123) {
        return;
    }

    $submission->uid = 0;
    $submission->remote_addr = '';
}

Implementing this in a module shouldn't be hard, just save the nids from the anon webforms.

nicholasruunu, I would not recommend that. That breaks webform functionality. If you want to limit the number of submissions per person, webform won't have their account/ip to verify against, so they can submit as many times as they want even if you set a limit.

@dwieeb, True, in my case that's not a problem though.

Webform 7.x-4.8 is now available, which includes this functionality. Users must log out to submit, and submission limit tracking is by cookie.

Alas, for our use case that isn't great and we still need this module -- it's an intranet, we don't want users to have to log out to complete surveys.

And since tracking is only done by a cookie, the webform submitter can get around that with a multitude of ways.

@kyleheney: This module cannot guarantee anonymity from everyone. The intended audience of anonymized results is Drupal administrators/users (those without direct database access). (Also keep in mind this is Drupal 7/Webform 3 where not everything can be exposed by simply making a view). Also keep in mind true anonymity is foolish to seek on the internet. Even if database records were wiped upon save, as I mentioned earlier, there are server logs, access logs, etc. from which results can be gleaned with enough time and effort.

Great update on the Webform module @DanChadwick.... tons of great additions, including the Confidential option.

I agree with @ReneeS though... for internal forms, this doesn't solve the issue.

@dwieeb... I agree that true anonymity is not possible, but wiping out submission information like username, IP address, and time of submission provide enough anonymity for most, in my opinion. It's this sort of functionality that a module like this could offer to provide confidential internal form submissions. I realize that Webform 4 is now using Views, which complicates things, but I think that if the submission information could be wiped out upon submission, this shouldn't really matter. Again, I don't know if this is even possible, but that was what I hoped was accomplished with an "Anonymous" module like this one. In my opinion, no user (even admin) should be able to view submission information if a form is advertised as being anonymous.

It's possible, but like I said it breaks Webform functionality for limiting the number of submissions a person can do. If you don't care that a user can continually submit a webform any number of times, then by all means wipe their information before it gets to the database. Otherwise we need to track their identity somehow to make sure they don't do that. My solution was to hide the data before anyone who wasn't a database administrator could see it. This is a common security practice used for auth keys, hashed passwords, sensitive user information, etc.

dwieeb's aproach makes sense: I tell my users up front that I (and only I) will have access and only if I set my mind to it; and offer them the option to clear the results when they're finished. My only issue at this point is the fact that the Views integration doesn't use the hook functions to retrieve its information. And I'm not sure why it can't, though possibly what I'm wanting is technically non-trivial.