Global webform submissions purge settings

Hi, this is a great idea. Thank you.

I figured I would use this solution for a separate issue I have with the draft settings not updating. When I applied the patch I found that the patch for 6.1 is colliding with the committed solution for Issue #3249092: Disable 'Allow users to post submissions from a dedicated URL' for all webforms, https://www.drupal.org/files/issues/2022-08-19/3249092-11.patch → .

Specifically: webform_update_863

/**
 * Issue #3249092: Disable 'Allow users to post submissions from a dedicated URL' for all webforms.
 */
function webform_update_8637() {
  _webform_update_admin_settings();
}

/**
 * Issue #3118427: Global update purge settings.
 */
function webform_update_8637() {
  $config = \Drupal::configFactory()->getEditable('webform.settings');
  $purge = [
    'default_purge' => WebformSubmissionStorageInterface::PURGE_NONE,
    'default_purge_days' => NULL,
  ] + $config->get('purge');
  $config->set('purge', $purge);
  $config->save();
}

Thank you!

I moved the update_hook to a post_update_hook like @hchonov did for the patch #15 ✨ Global webform submissions purge settings Needs review for 6.1.x since this does not cause collisions with the update numbers of hook_update_N()

Re-rolled the patch from #21 for webform 6.2.x

Hello. I have a different use case but came across this issue when looking into the webform submissions delete form whether it would be possible to extend/path it for my use case. On a customers site the webform spam protection was not configured strong enough and now we have almost 40,000 submissions in a webform, of which 98 - 99 % are spam. With data analysis (# submissions per ip adress, email address etc.) and what is available I managed to marked most of the spam submissions as locked, with less than 500 remaining which the customer has to check manually.

So far so good. The next step is to clean the data tables from the spam submissions. My idea is to add an option to the clear (and purge) forms to only delete submissions which

• * are locked (in my case the spam is locked)
• * are not locked (in a case where it is easier to identify and lock the submissions to keep)
• *ignore the locked state (current behavior)

As that could become a per webform or global purge setting as well and thus affect/extend the implementation of this issue, I first want to hear your opinion about it.