Only email results, don't store results on the site

Yeah, this is cool idea, you will save a lot of space on database innit ? +1 on this, I also would like only email submision. Results stored on the site are very good but when it grown, then your database will also grown and website might be slow :P

Does anyone know if this is possible? I'd be interested in it.

We have a large site with lots of forms and since the results are being e-mailed to staff, they likely aren't going to look at the results on the site. So not storing these in our database will save a ton of space.

I'm also very interested in this.

I'm sure this must have come up before but I can't see any other issues discussing this.

+1

We have a form that can't store the data due to legal issues. This would be very helpful for us.

+1

+ 1

We also have forms that can't store data due to legalities. Would be very useful for us too.

I solved this by putting some code into the Additional Processing section that will just delete any entries from that node. Additional Processing actually runs before the data is stored so it doesn't delete the current submission so that gets stored. But the net result is at most a couple entries... at least that keeps it from running amok. We had considered just running a cron job to clear the tables out but thought maintaining a list of WebForm IDs to clear (since we don't want to clear them all) would be more work... so we just add the bit of code into the WebForms we want to self clean. Unfortunately I do not have the code in front of me but it was not to hard. WebForm module has a function to call for deleting them and Additional Processing has available all the data you need to call that function. I recall it being just one line of code.

Nice idea, we have forms that need to stay very confidential, so this feature is very welcome.

This is exactly what I am looking for. I need to eMail some details of asipiring registrants to an administrator. Those details should not be persisted in Drupal's database, for various reasons (not least - confidentiality / security).

I was considering Additional Processing to delete the rows just entered (as jack.r.abbit suggests) but thought to check here first.
A field attribute to flag 'don't save it, just eMail it' would be even better.

I am now at Drupal 6.12.

Can anyone help me with this? Thanks

I would also be very interested in this functionality.

I too would love this functionality. But I cannot seem to get the post processing to work. Anyone have some code?

I'd rather see the option to do both, store them on site and export/delete/clear so you can save them as .pdf files else where. It's a win win, you can always clear them from the database when it grows too large.

I'm on a similar boat, I would like to have the form turn into a printable page for the user to print out and not get stored due to legal formalities.

Great module but +1 for an email-only feature.

Cheers

Dave

+1

The optimal solution would be a check box on a per-field basis similar to the email toggle that stores, or un-stores certain fields, that way, certain information can be kept and some can be excluded.

subscribe

--- created duplicate http://drupal.org/node/678188, sorry and thanks for quick reply QS.

The optimal solution would be a check box on a per-field basis

I'd probably disagree here, because this would affect the display, analysis, and export of submissions. I think a more likely solution is going to be all-or-nothing storage of submissions on a per-node basis.

Regarding space considerations, you would need a massive number of submissions to cause a significant slow down. I'm aware of a few sites that have literally billions of rows in the webform_submitted_data table, yet the site still accepts and handles webforms fine (though loading analysis or exports on forms that have tens of thousands of submissions is difficult).

Anyway, I'm also interested in having this functionality as a (per-node) option. Moving this feature to the 3.x version.

What if a checkbox is provided to admin during form edit to where if checked, then after each form submit, the "Clear" action is run automatically for that form? Reference http://localhost/node/*/webform-results/clear

With this method I would think that each form would still be stored briefly but then immediately erased.

I had to come up with a solution for this recently, here's what I did:

I created a Hidden field in my webform called "nosave", and gave it a default value of 1, then modified webform_client_form_submit() in webform.module to not save to the DB if this flag is detected. This gave me a quick way to turn it on or off for particular webforms. Here's how to modify the code in webform.module (sorry I don't know how to make patches, maybe somebody else can help with that):

1. Find the block of code which saves to the DB, it looks like this (around line 1720 in my version):
   

     // Save the submission to the database.
     if (...) {
       ...
     }
     else{
       ...
     }
   

   Change it to this:

     // check for hidden "nosave" field
     $save = empty( $form_state['values']['submitted_tree']['nosave'] );
     if( $save ){ // new if block
   
       // Save the submission to the database.
       if (...) {
         ...
       }
       else{
         ...
       }
   
     } // end of new if block
   

2. One more problem.. the email code reloads the submission data from the DB to construct the email, this obviously isn't going to work if we haven't saved it (you get blank emails). Find this line (it's right after the database code):

       $submission = webform_get_submission($node->nid, $sid, TRUE);
   

   and put it in an if() block as well:

       // only reload from DB if we saved it
       if( $save ){
         $submission = webform_get_submission($node->nid, $sid, TRUE);
       }
   

That's it! Any form with a "nosave" hidden field with non-zero value will not save, but email will continue to work fine. Webforms without this "nosave" field (or with a zero/blank value in it) will continue to save normally.

Hope this helps someone. Sorry it's not a cleaner solution, but because of the way the email code loads the submission from the DB, there's no true way of having "email-only" mode without altering the module. (It might be possible, as others here have suggested, of deleting the submission after the email is sent, but I preferred to prevent it saving entirely)

One other thing, if you go this route, make sure to change the project name in webform.info (I usually add " (Fork)") to prevent it from trying to update, which would delete the changes.

Incidentally, a better solution (and approach for a real patch) would be to add a tinyint "nosave" field to the webform table, add a checkbox for it in webform.pages.inc's webform_configure_form() function, and use that instead of a hidden field.

But on this particular project, I didn't have access to the DB, so had to improvise. ;)

Yeah to be included in the project this needs to be done the "real" way, and adding a database column is definitely involved (and writing an update function). If we ever implement #254979: AES encrypt webform submissions, I imagine we should be able to share this same setting. Therefor I think it would make sense to create a column named "storage" and have it be a string, so there could be any number of ways to store a submission. I'm talking about a long-term plan here, for this issue of course we don't need to worry about anything more complicated than just keeping setting "none" as the storage mechanism.

That's great Brian, thanks!

Very interested in this

Nobody has a clue? I'm very interesting in that problem :)

diego.nava, you can follow my instructions in #19 to achieve this result with a hidden "nosave" field.

The downside is you have to modify the actual module code (so you're effectively forking off your own custom version of webform), but I think this is necessary until such a feature is officially supported by webform, unless you want to delete the webform submission data after-the-fact (as suggested by jack.r.abbit in #7)

An interesting and practical feature might be to have a function that automatically deletes the data after specified period say 30 days, 2 weeks, etc.

That is a nice idea espirates. A little cron that comes in and cleans it all out. Then you could set it to everyday if you wanted. Or if you were required to keep records for 30/60 days you could set that up too.

I needed something like this, just installed webform php and added this to additional processing for that webform:

<?
module_load_include('inc', 'webform', 'includes/webform.report');
webform_results_clear($node->nid);
?>

clears out everything but the latest submission, with a little tweaking it'd take care of that too.

We decided to have the table clear all of the results (for that form) after it has emailed a copy through to the designated email address(es).

To do this we identified the node id of the form (in our case 20) and added the following line to line 1884 of webform.module [directly below the closing bracket of the foreach loop ($emails as $cid => $address) - which starts at line 1862]

$node = node_load('20');
$submissions = webform_get_submissions('20');
    foreach ($submissions as $submission) {
webform_submission_delete($node, $submission);
    }

I've tried your solution (6.x-2.9 and 6.x-3.0) but then every webforms of the site use the same confirmation message (corresponding to the nid used in the code added on webform.module). The email is sent well, but the user is then redirected to the confirmation message of the other webform and the "back to form" button also redirects to the wrong webform.

To make it node-specific for the time being, add the code mentioned by peligrorice in #28 to the end of the node-specific webform.email.tpl

That way it will only clear data for the specific node. At the time that the emails get sent, the submitted data is already in the db, so it will clear everything, including the current submission.

Thanks for your suggestion, #31. I have tested it and it works. It only has a problem, since now it is not possible to edit email webform options. When trying to access http://example.com/node/[nid]/webform/emails/1 now the web shows the template, instead of the options. Anyway, its a minor problem, since I just have to temporally delete or rename the node-specific webform template in the case I want to make changes.

It would be nice that "don't store the results" was an advanced option for each webform, as "Show the notification about previous submissions" or "Allow users to save a draft".

Yes please, this would be a useful feature.

Another approach could be to add a setting where one could enter the maximum stored submissions,
or a time setting, for instance 3 months.

The database could be purged with every new submission, or by using cron

This way you get more flexibility

I have written a small module to get this feature. It it not puhblished on drupal.org yet.
Before activating the module please backup your database.
Please give me feedback on this. I would then talk to quicksketch if this feature will be implemented within the next upcoming versions or if it should be posted as its own module.

Link to module (german site): http://www.sense-design.de/tutorial/drupal-6-webform-daten-nicht-datenba...

Looks to me like the add-on module br03tch3n wrote would work just fine for people needing this feature immediately. I'd prefer to see this as a per-form option as outlined in my post in #21. I'm definitely open to this as built-in feature of Webform.

I see that. Waiting for your implementation.

This would be great for making contact forms. I only want contact forms to email submissions to the recipient. There's no need to keep track of submissions in the databases in this case.

I'm going to take a stab at implementing this idea, per #21. I'm going to start with two storage models, "Database" and "None", with Database being the default. I will also try to add a hook in here to allow other modules to insert more storage models.

Here's my first stab at a patch.

* Added a new field to the Form Settings tab: Storage Model
* Added storage_model field to schema
* Created update function
* Updated webform_client_form_submit() to only store submissions if Storage Model is set to "database"

Usual caveats: backup your database/module first, etc.

The update function works, and sets all existing webforms to "database" for their Storage Model.

Have not tested sending emails yet, but setting the Storage Model to none does indeed not store the submission in the database.

I'm a little unsure what affects not having $sid defined within webform_client_form_submit() will have. It *seems* to work ok, but I will investigate that more in the morning.

I built this patch off of 6.x-3.x-dev so changing the issue version to match.

Tested sending of emails, and that works fine.

Subscribed. Also, #35 works great for now.

will this great patch be applied to the official version?

Thanks for the excellent patch MarkFischer! It's a great patch but it needs a few changes:

- If the form's storage is set to "None", the entire "Results" tab should disappear or describe why results are not available. I'm leaning towards the latter, unless we want to get rid of the results tab for all forms that haven't yet received any submissions. I'd find that a little unusual, so a message explaining why no submissions are available seems like the best approach.
- This database update is not quite right. On some DB systems (pgSQL) you can't set a default value when adding a new column. You should use the not-too-often documented 'initial' setting to set the default value for the new column.

+  db_add_field($ret, 'webform', 'storage_model', array('type' => 'varchar', 'length' => '255', 'not null' => TRUE, 'default' => 'database'));
+ update_sql("UPDATE {webform} SET storage_model = 'database' WHERE storage_model = ''");

Should be:

+  db_add_field($ret, 'webform', 'storage_model', array('type' => 'varchar', 'length' => '255', 'not null' => TRUE, 'default' => 'database', 'initial' => 'database'));

Great patch though! Reviewers please comment if this patch works for you and if anything does not work correctly.

* Added more descriptive messages to results tab for cases other than 'database'
* Updated update function with 'initial' parameter.

That's a great point about the inconsistent message on the results tab. Thanks for the info on the initial parameter, is that documented anywhere other than the actual code for the db_add_field() function?

Also, I haven't looked at the 7x version of webform yet, but would it be helpful to build this patch against that version as well? Not sure how you're managing the two paths.

EDIT: Don't use this patch, forgot to remove a line in the install file.

Yeah I'll need to port this to D7 before committing it, both versions are maintained in-sync. Thanks for the updates!

I finally have my head around the 'initial' parameter. It works great in 6x, but I'm having problems with it in 7x. The 7x version fails to run the update correctly:

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the      [error]
manual that corresponds to your MySQL server version for the right syntax to use near '0='storage_model',
1='database'' at line 1

It seems to be related to that 'initial' parameter, but I can't figure out what I'm doing wrong. I also can't seem to find any good examples where the 'initial' parameter is used. The field does get added, and at least with MySQL, a default value is set for existing records.

It works fine, but I'd really like to figure out why the update isn't completely clean.

I realized that using this approach we won't have any way to keep track of files that have been upload (or delete those uploads either). Any ideas on how we could keep track of these? Or just have them sit on the server forever?

I think it would be fine to just leave forever and only provide url in the email. It seems the sole purpose is to limit any reference to a single email.

Maybe at some point provide some file management in webform settings.

Manual
- Delete all
- Delete files older than...
--- a time period
--- specific date

Auto
- Delete files older than...
--- a time period

Notify
Send admin notice when folder reaches a certain MB

It's probably not a good idea to leave them on the server without having *some* way to access/delete them. Where I work, we offer hosted drupal sites to departments where they do not have file-system access. Without a drupal front end to get at the files, they are effectively orphaned.

In addition to crutch's ideas about some file management options, there are a couple other ideas I had:

1. Don't allow file upload fields in webforms that don't store
2. Ignore the storage setting, and always store the webform in the DB if there's an uploaded file
3. Upload the file, but delete it at the very end. Add a hook to let people deal with the file some other way before its deleted

I favor #2 so far. It would be easy to add to my patch, and wouldn't add nearly as much scope cream to this issue as adding an entire file management system would.

Would IMCE work for department-specific-file-access, only allowing access to webform attachment folders?

---

I was thinking providing download and delete links in the email but may not work with multiple recipients.

2. Ignore the storage setting, and always store the webform in the DB if there's an uploaded file

I'd think that storing the webform values when a lot of people specifically count on Webform not storing the values for legal purposes could be a sticky matter. My preference would probably be to store the files indefinitely for starters and then figure out some way to manage them (like a time-based deletion) at another time. It was just a potential sticky point I thought of.

My preference would probably be to store the files indefinitely for starters and then figure out some way to manage them (like a time-based deletion) at another time.

I've tested this out, and this is indeed the current behavior. Files are uploaded, no submission is stored. Emails contain a working link to the uploaded file.

Looks like the additions of the new 'status' option for webform collided with my patch. I've changed the update function to webform_update_6324, and fixed a couple of other conflicts. New patch! See if this one works on the current dev.

Here's an updated 7x patch, built off webform-HEAD.

Heh, its hard keeping a patch up to date when the head keeps changing so fast :) Try this one!

If you are working on http://localhost the mail probably won't send and show that error. This confirms however that webform in fact sent it, but was unsuccessful because drupal didn't find the mail service.

...after I successfully got the patch to apply, everything seemed to work

Woo hoo! I'm glad someone was able to test my patch :)

No idea on the mail thing, other than what crutch suggested. None of my changes came anywhere near the mail functions in webform, and mail is working fine on the test sites I've brought the patch up on so far.

subscribe

Subscribe

Subscribing

subscribing

subscribing

Subscribe

I'm using the code from #59 with 6.x-3.9 and while the patch unsurprisingly fails to apply via the patch command it was easy enough to merge in by hand. So far it's worked like a charm

Hi,

Sorry for my nob question but how do I install the patch from #59 ?

Do I replace the webform.install with the webform-290448-6x-5.patch and rename it to webform.install ?
or do I copy the content of webform-290448-6x-5.patch into webform.install ?

...do some drupal search and research on patching modules. Open the module file, compare against patch, add the +'s subtract the -'s...or use GIT.

+1 Subscribing.

The patch didn't apply cleanly for me so I let git do most of the merging for me. I cloned the repository and merged the patch posted above on a revision where it applied cleanly then merged master into the optional-database-storage branch. I will try to keep this branch merged forward with security fixes.

git clone git://github.com/dbravender/webform.git

Dan

Subscribing

I'm still on 6.x-3.6 (yes, I know), but I was able to apply the changes in #59 by eye and it worked as far as it goes.

However I spotted a surviving reference to stored submissions - the templates/webform-mail.tpl.php blithely reports "The results of this submission may be viewed at: http://example.com/node/XX/submissions/".

The template claims that $node is passed through, so it's a simple matter of adding some logic based on $node->webform['storage_model']. I've made these changes and tested them a bit locally, and they seem to work - as I say, I'm on an old version, but the file seems to be identical in 6.x-3.11 so I've rolled a patch for just this file.

One more thing ... the "Thank you, your submission has been received" page has a path like "/node/XX/done?sid=" - I guess in theory we should remove the ?sid=, but it's not really doing any harm, so.

+1, Subscribing

Hope this feature also moves to 7.x

+1, Subscribe...

I attempted to apply 7.x patch from #57, however it failed.

Would love to get this working, any other clues/ideas?

Thanks,
-David

I know this patch doesn't work correctly. I'm new to patching. However the code inside the patch works correctly. And enables this feature in 7.x

Maybe someone can take the patch and format it correctly so it would work. I started with comment #57 and made those changes but in the latest version of webform.

Maybe quicksketch could implement this in the next release?

I want to echo the previous post. Installing the patch from #57 with Git fails, perhaps because Webform has changed since January. Can someone rebuild the patch so that it works on the latest version of Webform in 7.x?

We definitely need this to be implemented and soon. It looks like we have some people who spent time writing patches, but they don't work anymore. Can you implement this into your next version? For many of us, storing submitted data is a privacy issue.

#79 almost works for me on 7.x-3.11.

I've determined that if I toggle the database/none value in the database manually, everything works perfectly and saved submissions get toggled. the problem is that when you save the configuration form, the database/none setting does not get saved to the DB on node_save(). So the module functionality works, but the settings can't be changed in the backend, they have to be done manually in the DB (webform table) which is bad.

Anyone want to take a stab at getting it to save? I can't seem to figure out why changes to the conf aren't going into the DB.

EDIT: The setting saved on fresh install with 7.x-3.13, only I get this error, maybe because a non-saved submission does not have an sid? Regardless, I don't have mail on that server, so I can't test if emails are actually going out.

Notice: Undefined property: stdClass::$sid in _webform_filter_values() (line 2715 of ../sites/all/modules/contrib/webform/webform.module).
Notice: Undefined property: stdClass::$sid in _webform_filter_values() (line 2749 of ../sites/all/modules/contrib/webform/webform.module).

UPDATE:

I was able to test this on a real dev server and it worked just fine. I didn't even see the error messages. They still appeared on my fresh test install, though.

Can we re-roll #79 against 7.x-3.x-dev? I have a big need for this as well, but seems the issue hasn't been touched in a couple months.

Similar to bkosborne and the others who posted earlier, I would like to send emails using Drupal 7.x (7.12 specifically) using the Webform 3.x module without capturing the submission information in the results. I do not want to store any information pertaining to the user who submitted the form (e.g. submission contents, IP address, etc.). Within the "webform.report.inc" file there is a function "webform_results_clear_form($form, $form_state, $node)" maybe this can be integrated to immediately delete the contents generated by "function theme_webform_results_table_header($variables)" and "function theme_webform_results_table($variables)".

I noticed that the content populated to the results comes from multiple locations within webform.report.inc or elsewhere, so I'm hoping someone out there can help formulate a solution for Drupal 7. This will be hugely appreciated by myself and the numerous others that have been trying to resolve this issue! Thanks!

Removing tags. Please read the issue tag guidelines before tagging anything else. Thanks ;)

Hi Kingandy, I may have got a bit carried away with the tagging. Would you by any chance have a solution to port over your patch from #76 to Drupal 7 (maybe with the help of Infriger's #79)? I believe this is a crucial update to prevent data collection of end users while streamlining emails of submitted data. Any assistance would be huge as there is a bit of urgency.

+1 (re: Can someone rebuild the patch so that it works ON and is applied TO the latest version of Webform in 7.x?)

It would save us a lot of time since we applied this quite some time ago and the versioning seems to have caused some of Webforms updates since the application of the patch to have been skipped.

I believe this is a crucial update to prevent data collection of end users while streamlining emails of submitted data. Any assistance would be huge as there is a bit of urgency.

A short timeline on your project for you doesn't mean it's a critical feature for the Webform module.

If the current patch doesn't work, this patch should be in "needs work", rather than "to be ported", which implies that a patch is already acceptable on one of the current branches. The best way to move this forward is for patches to be rerolled and tested for both 6.x-3.x and 7.x-3.x. I'm extremely busy and this isn't the first priority for me, though I'd be just as happy as everyone else to see it implemented.

quicksketch, sorry if I confused the phrasing, but I wanted it to read that it is a crucial feature to prevent data collection and yes I wouldn't expect this to be a rush job for the module, I was just looking for some assistance with the current version of Drupal. I appreciate you pointing out and explaining the status meanings!

Would it be difficult to implement a module or patch that calls the function "webform_results_clear_form_submit" found in "/weform/includes/webform.report.inc" and execute "webform_results_clear($form_state['values']['nid']);" within that function that apparently clears all form content within the results section and proceed to do this after the form is submitted?

@saulg - for a quick 'n dirty solution (maybe that should be 'cheap and cheerful') you could probably make a node-specific confirmation page template in your theme folder and add these lines at the end of it:

<?php
$submission = webform_get_submissions(array('nid' => $node->nid, 'sid' => $sid));
$submission = webform_submission_delete($node, $submission);
?>

It's a little 'wasteful' as the data gets inserted and then immediately deleted, but I think it'll do the job. As far as I know the emails are already sent by the time the confirmation page displays.

EDIT: you may need to module_load_include the submissions.inc file before calling webform_get_submissions()

+1, would like to see this in the module.

If you've run email_only_pt2-290448-2 against 7.x-3.13, it 'pre-uses' webform_update_7314, so when you update to 7x-3.15, the system table thinks that webform_update_7314 has already been run, so it won't run that hook from the updated module.

In short, between email_only_pt2-290448-2 and webform-7.x-3.15.install, there are two copies of webform_update_7314! Drupal will only run one, and then consider it run once and for all!

If you have run the patch against 7x-3.13, you need to make a *new* patch that runs the webform_update_7314 within a newer update hook -- something like

function webform_update_7316() {
  webform_update_7314();
}

And then when a newer version of webform rolls around that itself uses `webform_update_7316`, you'll have to encapsulate your patch in a higher-level update hook again.

@quicksketch: Do you think it would be feasible to have a checkbox for 'Do not store data' (or similar) and set webform.submit_limit to -10 if it is selected? If there is no data in the database the submit_limit field is pretty much useless anyways.

We can then wrap a check for -10 in webform_submission_insert around the database insert stuff, without losing any of the hook functionalities etc. etc. that may (or may not) be applicable to each application.

To take a little pressure off this ticket (and quicksketch) I figured I would sandbox my module, Webform disable results, that uses the same concept as mention in #90. When there is a solution, I will post an upgrade path from 'Webform disable results' to 'Webform 6.x-3.x'.

I am not actively using D7 but it should be very easy to upgrade this module. If someone is up for helping ..that would great, if not then post the request in my issue queue.

@quicksketch: Do you think it would be feasible to have a checkbox for 'Do not store data' (or similar) and set webform.submit_limit to -10 if it is selected? If there is no data in the database the submit_limit field is pretty much useless anyways.

I'd really prefer a dedicated database column for this setting. Seems like the patch in #79 (though not working) is already pretty close. It probably just needs to be cleaned up and ported.

Ok, a little new at all this but I've taken #79 and applied it to my own install (7.12 with webform 7.x-3.17). Seems to have worked, I set the storage model for an existing form from database to none and did a test submission - email sent, no results stored.

Attached is the patch for the 7.x-3.x branch (which I'm calling 3.17 here so if the version bumps other still know what it's for). Feel free to do with this what you wish!

Looks like #95 is a winner. I patched Webform with it, and it works like a charm. Thanks for doing this. The email-only model is crucial for us as we deal with a lot of private information that can't legally be stored except in very specific locations.

Tested the patch from #95 a number of times/ways and it is working as intended. I had to back up our 'schema_version' one step because we were using an earlier patched version.

What else needs to happen for the patch to be accepted? :)

Would be nice if it GPG encrypted the form and sent it to admin.
Bonus if User can upload their own GPG ASCII armored key and have a copy sent to them encrypted as well

What format or encryption is used on the email is unrelated to whether form results are stored in the database - please create a separate issue to discuss this.

I think this would be great if it had some tests.

#95

I patched version webform-7.x-3.17
Now when I submit a form it is not stored -good!
But I do not get the results in the emails but instead the standard message:

"A visitor completed a booking request on your site. Please visit your website
and click the webform's "Results" tab to review the submission."

Any ideas?

Thanks!

UPDATE: Never mind I found a solution. For those who need the same as me -because I only needed the results send via email and for that you can use tokens as describet here: http://www.drupalgardens.com/documentation/feature/webforms#tokens

UPDATE: Never mind I found a solution. For those who need the same as me -because I only needed the results send via email and for that you can use tokens as describet here: http://www.drupalgardens.com/documentation/feature/webforms#tokens

I've had another crack at the functionality of @fourthandvine's patch in #95 and taken a slightly different twist.

You may specify that you do want submitted data stored on the site. You also have the option of not saving submission meta-data (user, time of submission, IP address). It made sense to me that there would be scenarios where we'd want to know if someuser had already submitted the form, even though we do not have the data that someuser submitted.

Instead of making changes to templates, these patches issue warning messages on the Submissions, Table, Analysis and Downloads pages that the form is not storing submitted data.

If you specify that data is not to be stored in the db and have not yet set up at least one email, you will see a warning message to the effect that data may be lost if an email is not configured.

Patches for D6 and D7 attached.

Please test so we can get this committed.

[edit] When you opt to not store data, but do store meta-data, then all the normal backend functionality (e.g. submission limits etc.) remains as standard (except of course that you won't have any submitted data).

Wow, nice one @vernond! Even though I made the suggestion of the general "storage" database column, I have to agree that this was unnecessary and confusing abstraction. The direct implementation is easier for developers and end-users to understand.

Regarding the message, I think we may want to use your existing function to check if storage is used, but perhaps provide customized messages in each situation the notice is shown. For example when clicking on the "Results" tab, instead of:

'The form %title is not saving submitted data.'

Perhaps we'd say something like this to clarify why the message is being shown, and say what you can do to re-enable results:

'The form %title does not have any results displayed because it is not saving submitted data. This option may be changed under the form settings.'

We also should probably disable the UI for limiting submissions if you are not tracking meta-data (or perhaps vice-versa).

perhaps provide customized messages in each situation

Mmm, do we really want customised messages per page/situation? Isn't translation good enough for that?

The form %title does not have any results displayed because it is not saving submitted data. This option may be changed under the form settings.

Very good idea!

disable the UI for limiting submissions if you are not tracking meta-data

Very good idea... I should have thought of that.

Sorry by "customized" messages I meant just specify separate messages that match the situation. String replace and translation are certainly good enough alternatives for admin-only facing messages.

Patches re-rolled to include @quicksketches suggestions in #105.

Thanks vernond. What do you think about using a single option (and db column) for this setting? Since you're really talking about 3 options, but two checkboxes gives you a total of four combinations (which is why you're hiding the second one when it doesn't apply).

Rephrasing into a single question it would look something like this:

Submission storage:
(•) Full submissions (provides draft ability, analytics and on-site review)
( ) Basic entry record only (e-mail only form, with submission limit options)
( ) Store no data at all (e-mail only form, disables submission limit)

Although the "Basic entry" option really could probably be eliminated also if we provided:
A) A basic "count" column in the "webform" table. And
B) #246470: Allow cookies as sole voter validation

Then submission limits would be possible even without any personal information of any kind. I don't know, I'm probably over thinking this.

Perhaps four options is indeed the way to go:

1 - Store meta-data, store submitted data (default, as we currently do)
2 - Store anonymised meta data (no username & IP, just time & sid), store submitted data
3 - Store meta data, but no submitted data
4 - Store no meta data and no submitted data

That will also cover some of the other requests we've had, like anonymous voting for example.

Basically we'd need to add some extra bits for option 2 as the other three options are currently possible.

2 - Store anonymised meta data (no username & IP, just time & sid), store submitted data

I'll have to think about that one. :)

Hi, I have a problem with a patch: webform-7.x-3.x-emailonly-290448-95-2.patch
When this error appears Form:

Notice: Undefined index: no_storage in webform_menu_load() (line 368 of C:\wamp\www\oko\sites\all\modules\webform\webform.module).

Can you help me?

Did you run update.php after applying the patch?

Thanks. I update all but after patching webform still store in "Results" a data.

In the end I ran the package, but again, I have some errors:

Notice: Undefined property: stdClass::$sid in webform_submission_insert() (line 131 of C:\wamp\www\oko\sites\all\modules\webform\includes\webform.submissions.inc).
Notice: Undefined property: stdClass::$sid in _webform_filter_values() (line 2943 of C:\wamp\www\oko\sites\all\modules\webform\webform.module).
Notice: Undefined property: stdClass::$sid in _webform_filter_values() (line 2981 of C:\wamp\www\oko\sites\all\modules\webform\webform.module).

Code webform.submissions:
http://wklej.org/hash/65d938292b2/
Code webform.module:
http://wklej.org/hash/cc54018ea54/

I am new to drupal and apologize for the dumb question - i can't find a way to have drupal automatically send an e-mail when someone completes a webform. How am I missing that?

Thanks,

Sharon

@magnetic marketing: Navigate to your Webform node, click on the "Webform" tab, then the "E-mails" sub-tab. Configure the e-mails there.

@quicksketch re #111 - So in my list of to-do's for the weekend I want to try get this thing wrapped up. I'm planning on shooting ahead with these options:

(*) Full submissions (provides draft ability, analytics and on-site review)
( ) Store anonymous submissions (provides analytics and on-site review, disables submission limit)
( ) Store submission user data only, no submitted data (e-mail only form, provides submission limit)
( ) Store no data at all (e-mail only form, disables submission limit)

Second option will set uid to 0 and IP to 127.0.0.1, store timestamp and sid.

Second and fourth options would, I imagine, require that we explicitly NOT use cookies?

Thank you so much. Hopefully one day I will be a contributor to the cause.

Sharon

@vernond: I'm not sure about our new approach either. Seems like we're making things awfully hard for our end-users. Considering if we A) provided #246470: Allow cookies as sole voter validation and B) kept a separate submission count table we wouldn't need to present so many options since all functionality of Webform could be maintained without storing any personal information.

@quicksketch: In the case of a form only open to logged-in users and in a not totally democratic environment (such as a workplace or a club for example) there would not be any way for admins to determine who, from a list of registered users, has not yet participated in a poll/survey where anonymity of opinion is required - i.e. we don't need to know who said what, but we need to know that everyone has had their say.

On the other hand, it does seem to me that your suggestion is better suited to Webform core and mine perhaps better suited to a separate module. I'll toy with it from this point of view for a bit.

there would not be any way for admins to determine who, from a list of registered users, has not yet participated in a poll/survey where anonymity of opinion is required

Right that's true, though in such a situation the person who built the form would knowingly disable database storage of the results, I don't think they'd expect such an ability (other than keeping a manual tally of the results that came into their inbox).

Hi, Quicksketch - I have another quick question. Is there any way to remove the "Submitted by AACSchool on Mon, 06/04/2012 - 10:29" line at the top of the Webform page?

Thanks.

@vernond - this is great and I really appreciate your work on it. I updated webform to 7.x-3.18 a week or so ago which fixed a few bugs and your part of your patch is failing.

Hunk #3 FAILED at 245.
1 out of 7 hunks FAILED -- saving rejects to file includes/webform.report.inc.rej

I have it configured to not save any data, meta or otherwise. The form works and the emails are fired off and no data is being saved but it's throwing the following after saving.

Notice: Undefined property: stdClass::$sid in webform_submission_insert() (line 132 of /xxxxx/sites/all/modules/contrib/webform/includes/webform.submissions.inc).
Notice: Undefined property: stdClass::$sid in _webform_filter_values() (line 2943 of /xxxxx/sites/all/modules/contrib/webform/webform.module).
Notice: Undefined property: stdClass::$sid in _webform_filter_values() (line 2981 of /xxxxx/sites/all/modules/contrib/webform/webform.module).

Any way we can talk you into rerolling for 7.x-3.18?

Thanks,
Tim

Would it be right to think to stop processing or saving on :

mymodule_webform_submission_presave($node, &$submission) {
# some processing here
}

Looking through the source it seems _webform_submission_presave is called first but fiddling $submission throws errors for eg.

function mymodule_webform_submission_presave($node, &$submission) {
	if($node->nid == 20){
		unset($submission->data);
		return FALSE;
	}
	return TRUE;
}

Above code produces errors:

    Warning: Invalid argument supplied for foreach() in webform_submission_insert() (line 110 of /srv/www/htdocs/citron/sites/all/modules/webform/includes/webform.submissions.inc).
    Warning: Invalid argument supplied for foreach() in _webform_filter_values() (line 2941 of /srv/www/htdocs/citron/sites/all/modules/webform/webform.module).
    Warning: array_diff_key(): Argument #2 is not an array in _webform_filter_values() (line 2964 of /srv/www/htdocs/citron/sites/all/modules/webform/webform.module).
    Warning: Invalid argument supplied for foreach() in _webform_filter_values() (line 2965 of /srv/www/htdocs/citron/sites/all/modules/webform/webform.module).

@vernond #119, wouldn't it be better to use an IP address like 0.0.0.0 instead of the localhost default IP for the anonymous submissions?
My concern is the Drupal instance might be running on localhost at all times, and all authenticated and anonymous user IPs would be same 127.0.0.1

As far as I know, 0.0.0.0 cannot be assigned to any machine, thus would be a safer option. Plus, could provide an easier option for filtering results in the reports.

Just checking in here. I read most of this thread toward the end. Is this still only a patch? It is not currently in the 7.x-3.18 module and I don't see any options there.

@finedesign: Yes it's still only a patch. At this point the functionality will only be added to the 4.x branch as we're not adding features to 3.x any more.

Changing version to 7.x-4.x-dev per #129.

Can the patch be applied to the current 4.x branch or is it specifically for the 3.x branch?

In #35 I posted a small module to get this to work for D6. I have now created a sandbox project to centralize this on Drupal.org. A D7 version will follow in the next days. This is for the people who need this feature immediatelly. As mentioned in #36 this will be a feature within Webform sometime.

UPDATE: The D7 version is now also included. Haven't tried testing on the current 4.x branch, 3.x works well.

Webform NoSave Module (Sandbox)

hii i am new bee in drupal world, and my boss has assigned me an project to developed an portal in drupal. i have one webform which is for request, as soon as the employee submits the form an e-mail should be send to his manager, manager approve his request and should be able to submit the same form after updating it and this updated form should be mailed to group head. i am struck at this point is there any think plzzzzzz help me...........
i am attaching the image of workflow of the mails as how the same submission will travel from one person to another.

@vaibhav_jadia your request is not really related to this thread.

That being said, I do not think you should be trying to use Webform for what you're describing. Webform is for super simple data collection. For anything more complex (especially involving workflows) you should probably be looking at creating nodes (ie, define a new Content Type called "Employee Request" or whatever), and then use modules like Workflow and/or Revisioning. Check out this tutorial: http://drupal.org/node/408052 (which also touches on setting up Email notifications via Triggers).

I would love to use this sense-design, but I can't figure out how to install it from the git clone http://git.drupal.org/sandbox/sense/1895002.git webform_nosave information provided. I know how to install a module, but I don't know what to do with this? Can you provide an explanation to a newbie? Thanks!

You can download a snapshot tarball (tar.gz) archive of the files from the repository viewer - http://drupalcode.org/sandbox/sense/1895002.git/snapshot/refs/heads/7.x-...

I've been testing (for an hour) #132 sense-design with the Webform 7.x-4.0-alpha6 version.
Works great until now.

sounds great, thx for the feedback

I've been testing the sandbox module with 7.x-4.0-alpha6 and noticed that uploaded files were not deleted. See #1973750: Use webform_submission_delete so uploaded files are deleted as well

Thanks sense-design for the module (#132), it also works for Webform 7.x-4.0-alpha8.

Thanks for the feedback, will update the sandbox module description

I was originally looking for the solution for saving the submission after i put drupal_goto() inside my hook_webform_submission_presave() (After my drupal_goto(), the submission doesn't get stored.). Then I found this thread. My current situation would be the work-around solution you might be looking for. Hope this would help someone.
To sum up,
when you implement your hook_webform_submission_presave(), if you use drupal_goto() to redirect, your submission will not be stored.

Just a confirmation for anyone else that might read through... I'm currently using sense-design's Webform NoSave Module from #132 with 7.x-3.19 and it's working perfectly. Thank you for this!

There is a module for this: https://drupal.org/project/webform_clear I've just begun testing it so I can't confirm how well it works, but it's worth looking into

I'm closing this since there seems to be two add-on solutions (one sandbox, one official), and I don't see including this feature within webform itself.

+1 to adding this feature as an alternative to installing additional modules/patches.

+1 This would be a very helpful feature for drupal 7 users (including myself) who want to play safe with GDPR-rules.
It's very relevant.