I have been testing your sandbox with Webform 7.x-4.0-alpha6. Not everything worked as expected: uploaded files were not deleted. I think it's better to use the webform_submission_delete() function instead of going into the database yourself, because it invokes all relevant hooks, causing files to be deleted.

My webform_nosave_delete_result() now looks like this:

/**
 * Delete result from db
 */
function webform_nosave_delete_result($form, &$form_state) {
  $sid = $form_state['values']['details']['sid'];
  $new = $form_state['values']['details']['is_new'];
  $nid = $form_state['values']['details']['nid'];

  $nosave = db_query("SELECT COUNT(nid) FROM {webform_nosave} WHERE nid = :nid", array(':nid' => $nid))->fetchField();
  if ($sid && $new && $nosave) {
    module_load_include('inc', 'webform', 'includes/webform.submissions');
    $node = $form['#node'];
    $submission = webform_get_submission($nid, $sid);
    webform_submission_delete($node, $submission);
  }
}

Comments

sense-design’s picture

Status: Active » Closed (won't fix)

Files are not included in the mail as attachments just a link to the file, remember that, this is why I mentioned this on the description page of this module. If I would use the normal delete function from webform, the files would be missing completely.

marcvangend’s picture

Status: Closed (won't fix) » Active

Files can be attached to the email if you use the mimemail module.

I need the NoSave option because of legal issues; I'm not allowed to keep submission data on the web server. If this module claims to stop Webform from storing submissions, I expect it to do delete everything. It's up to the site builder to make sure the submitted data is sent somewhere else - after all he must also configure the email settings.

sense-design’s picture

Ok, haven't checked this, so if the mimemail module is active it is possible to send the attachments via configured mail? If so, I could provide a patch respecting the mimemail module and perform a total clearance based on the "delete" function from webform.

Is there a special variable in mimemail module which i could check if the files of webform get attached to mail?

marcvangend’s picture

I'm just looking at the code right now (my machine with all the running code is at work), but if I understand correctly:

Webform module is checking if the mimemail module is enabled in the webform_email_html_capable() function in webform.module. If mimemail is enabled, webform is able to send HTML emails and/or add attachments to the emails. For each email that is defined for a webform, settings are saved in $node->webform['emails'][$eid]. Looking at line 274 of webform.submissions.inc, I see that the setting that uploads must be sent as attachment, is in $node->webform['emails'][$eid]['attachments']. So, if any of the defined emails has the 'attachments' value set to 1, you can delete the uploaded files.

BTW this is all based on webform 7.x-4.0-alpha6, I didn't check if other versions are different.

sense-design’s picture

So what I have to do is:

  1. Check if mimemail module active
  2. Check if mimemail setting is set in current submitted webform
  3. If yes, do webform delete otherwise keep file to download via http/ftp

Anything missing?

marcvangend’s picture

Sounds fair, but we may be missing a possible use case here. Suppose I have a webform which sends out two e-mails - one with attachments and one without - but I still want the mail receiver without the attachments to be able to download the files. That would not be possible in the suggested workflow, right?

Maybe it would be better to add a second checkbox to the webform_configure_form, which is only available if mimemail is enabled AND the nosave checkbox is selected. Code could look something like this (disclaimer: untested code!):

      $form['advanced']['nosave_attachments'] = array(
        '#type' => 'checkbox',
        '#title' => t('Also delete submitted files from disk'),
        '#description' => t('Check here, if you do not want to store uploaded files on disk. Make sure to add the files to one or more e-mails as attachment.'),
        '#default_value' => $nosave_attachments,
        '#access' => webform_email_html_capable(),
        '#states' => array(
          'visible' => array(
            ':input[name="nosave"]' => array('checked' => TRUE),
          ),
        ),
      );

The value (0 or 1) of nosave_attachments could be stored in a second column in the webform_nosave table. In webform_nosave_delete_result() you would select both the nid and the nosave_attachment value from the database and perform the desired action.

sense-design’s picture

Good idea, will provide a patch for testing after some sleep

sense-design’s picture

First patch, please try and give me feedback

sense-design’s picture

Wrong spelling of "attachements", missed the "s" at the end

sense-design’s picture

When the submission gets deleted via webform api the redirect runs into 403 page, fixed in this patch

marcvangend’s picture

Thanks, I was away for the weekend, I'll try to test it tomorrow.

sense-design’s picture

Any feedback on this?

sense-design’s picture

reminder

sense-design’s picture

Issue summary: View changes
Status: Active » Needs review
heddn’s picture

Status: Needs review » Needs work

I wouldn't put this dependent on an email module. I'm using webform to call a web service. I send the files as a BLOB of data to the service. Then I want to delete the file. The file is a scanned copy of a national id card, passport, drivers licence, etc so I can't have it laying around gathering dust on the server.

heddn’s picture

Status: Needs work » Needs review
StatusFileSize
new6.23 KB
new4.79 KB

Here's an attempt at fixing the above mentioned issue. I also added a check that the field isn't already in existence into the hook_update_N since the hook_schema already should create the field, except in the case of upgrades of existing installs. And a hook_module_implements_alter to make sure that our hook_form_alter comes last. And I don't see any reason why we can't use the api provided delete for all cases. Who knows but that another webform contrib module also needs to run some cleanup.

fmizzell’s picture

StatusFileSize
new7.08 KB
new2.71 KB

This patch does not add any new functionality, just a little bit of code clean up.

fmizzell’s picture

+++ b/webform_nosave.module
@@ -15,6 +15,22 @@
+  if ($hook == 'rdf_mapping') {

here it should be checking for form_alter, not rdf_mapping ... right?

fmizzell’s picture

StatusFileSize
new7.08 KB
new622 bytes

patch with the fixed mentioned in #18

sense-design’s picture

Having review on this, thanks guys