Allow users to personalize the submission list

Added proof of concept patch that seems to allow customization on a per-user basis.

I'm not entirely convinced that using \Drupal::state is appropriate for this kind of thing after introducing this much granularity. While is was perfect for storing the global state, it almost seems like the wrong tool for storing per-user information.

Copying the patch from slack seems to have corrupted it. Trying again...

What are your thoughts on making an (abstract?) base class form to be able to recycle most of the form build? Using two forms could also allow for a cleaner separation of persistence logic. It should also let the existing form remain intact for BC reasons.

I'm also wondering if the new form should have its own link on the results page such that there could be a "Set Defaults" and/or a "Customize" (bikeshed needed) button that appears depending on the user's permission. This could allow more logic to be nicely separated, especially when a user has permission to edit the webform default as well as their own personal results lists.

This week is going to be busy, but I should have more time next weekend to get at least part of a rough working patch put together.

Added configuration related changes.

Ouch. Added webform settings update call to update hook.

Passing config changes.

I think this is more of an "enterprisey" feature that is useful when more than one individual is involved in site management, and none of whom should be able to administer webform settings.

Our particular use case involves different types of stakeholders that all care about different data. For example, marketing associates want to see campaign related information (who clicked what, where did they come from, etc...) whereas others want to see other subsets.

Having multiple parties attempting to view data all at once can be disorienting (especially if someone else changes the view while you are using it). Having enough permission to customize the results also currently carries more implications.

• Add call to delete user-specific webform configuration on delete.
• Adjust update hook N.

Hey Jacob,

I was able to take a pass through the changes (sans tests -- I'll try to run through those tomorrow night). Overall, it's a work of art. I have just a couple pieces of feedback.

1) The \Drupal\webform\Form\WebformResultsCustomForm form seems to continuously render a 'Customize my table' link for users that have access to customize their personal table, but not set the defaults. Perhaps this could be a fix:

diff --git a/src/Form/WebformResultsCustomForm.php b/src/Form/WebformResultsCustomForm.php
index 2b8222be8..e8c1ca11b 100644
--- a/src/Form/WebformResultsCustomForm.php
+++ b/src/Form/WebformResultsCustomForm.php
@@ -150,7 +150,7 @@ class WebformResultsCustomForm extends FormBase {
           '#suffix' => '</p>',
         ];
       }
-      else {
+      else if ($this->type !== static::CUSTOMIZE_USER) {
         $route_name = $this->requestHandler->getRouteName($this->webform, $this->sourceEntity, 'webform.results_submissions.custom.user');
         $route_parameters = $this->requestHandler->getRouteParameters($this->webform, $this->sourceEntity);
         $url = Url::fromRoute($route_name, $route_parameters)

2) The \Drupal\webform\WebformSubmissionStorage::getCustomSetting method could potentially allow user-specific customizations to be used even if the webform configuration forbids it.

To POC this, add a user customization to a form that's different than the default, then disallow user customizations. Refresh the page and see that the user customized settings are still used.

diff --git a/src/WebformSubmissionStorage.php b/src/WebformSubmissionStorage.php
index 206eb72dd..4a366dc7e 100644
--- a/src/WebformSubmissionStorage.php
+++ b/src/WebformSubmissionStorage.php
@@ -897,6 +897,8 @@ class WebformSubmissionStorage extends SqlContentEntityStorage implements Webfor
 
     $key = "results.custom.$name";
     if (!$source_entity) {
+      // I think we might need an access check here.
+      // Or perhaps clear out user data if a webform is updated to forbid user customizations?
       return $webform->getUserData($key)
         ?: $webform->getState($key)
         ?: $default;

I'm a little confused by some of the WebformSubmissionListBuilderCustomizeTest test. If I'm not mistaken, the test seems to be broken -- or at least not working like I'd expect it to.

diff --git a/tests/src/Functional/WebformSubmissionListBuilderCustomizeTest.php b/tests/src/Functional/WebformSubmissionListBuilderCustomizeTest.php
index 381b18144..9f741dcb2 100644
--- a/tests/src/Functional/WebformSubmissionListBuilderCustomizeTest.php
+++ b/tests/src/Functional/WebformSubmissionListBuilderCustomizeTest.php
@@ -244,8 +244,9 @@ class WebformSubmissionListBuilderCustomizeTest extends WebformBrowserTestBase {
     $webform->setSetting('results_customize', TRUE)->save();
 
     // Check that 'Customize' button and link are not visible.
+    // This part *should* fail, right?
     $this->drupalGet('/admin/structure/webform/manage/test_submissions/results/submissions');
-    $this->assertLink('Customize');
+    $this->assertLink('Customize'); // <-- $this->assertNoLink('Customize') ?
     $this->assertLinkByHref("${base_path}admin/structure/webform/manage/test_submissions/results/submissions/custom");
 
     // Check that 'Customize my table' button and link are visible.

Running through the steps manually in my browser, I can confirm that a webform set with 'results_customize' should only show the 'Customize my table' link on the submission table and not the 'Customize' link. I'm not sure where the test is finding a 'Customize' link on that page.

* AH! It looks like \Behat\Mink\Element\Element::findAll can fall back to doing partial matches. Why the link was found now makes sense.