Provide Default View to Override Submission Results Tab

The attached patch has no test coverage. I just need to confirm that it is not breaking anything.

I just messed up and merged 2993327-views with 8.x-5.x and I reverted the changes and will create a new branch.

Hopefully, this final patch passes all the tests and this change can now be reviewed.

I created a change record to help people understand how views integration is set up.

A few notes about the original feature request.

• It is difficult and hacky to provide additional result tabs for each view which is why multiple views are displayed in a dropdown.
• Overriding an individual webform node's results with a view is not support but could easily done via code. For example, it is possible to write hook that looks for an 'embed_node_NID' view display id and dynamically override a webform node's results with that view display.

@see https://www.youtube.com/watch?v=Qs_m5ybxeXk

Cool video out there! :)

I reviewed your branch and also checked it out locally to actually execute your code. While reviewing your code I found this spot, which looks like a logical "misspelling" to me (it's WebformSubmissionListBuilder):

    $displays = $view->storage->get('display');
    if (isset($displays[$display_id]['display_options']['arguments'])) {
//////// In both branches of of this IF statemente you're doing the same assignment.
/////// I believe you meant rather
////// display_arguments = $displays[$display_id]['display_options']['arguments'];
////// in the line below.
////// So that way you take the "current" $display_id arguments if they are available and
////// the default ones otherwise.
      $display_arguments = $displays['default']['display_options']['arguments'];
    }
    else {
      $display_arguments = $displays['default']['display_options']['arguments'];
    }

As I told you in an email, in webform views I also at some point faced a similar task, but actually the implementation (and needs of our client) were slightly different. There we would let the client build a normal view for a webform A and have its URL be /form/webform-a/my-cool-view, then they'd expect this view to nicely integrate with routing, i.e. display local tabs in both directions: when you're on the URL form/webform-a, among others, there must be the tab that leads to the view.. and other way around, whenever you open /form/webform-a/my-cool-view we had to show all "normal" webform tabs.

Then they'd repeat the same for webform B (and would place it under URL /form/webform-b/my-cool-view-or-any-other-url) and would expect again this new view to nicely integrate with the Routing system. The condition was that they are placing such views as a "subfolder" of the main webform route. But we did not substitute the pre-existing routes.

I assume I could refresh my memories about how I managed routing in webform views for that part (actually the stuff I described above is part of webform_views, I decided to put it into a contrib module instead of just keeping in a custom one within the project; hoping that one day I'll have time to polish it and allow users to do some cool stuff on top of that). So I could refresh my memories and maybe offer a way to inject the submission views as a tabs and not as a dropdown list. But to be frank, it would mean a 3rd level of tabs and I do not think that is UX-friendly. I actually liked the dropdown list you have placed :)

@bucefal91 Good catch on the coding mistake.

I did not see any clean way to implement a third level and/or dynamic tabs to display webform submission views, especially because several admin themes have different ways of handling local tasks (aka tabs).

Views ability to add new local tasks/tabs to existing menu items and tabs is very limited. If have found any solution that helps solve this problem, please consider contributing it back as code or documentation.

And do you want to provide these tabs as 3rd level or append them to the 2nd level? By "3rd level" I mean more or less like you have done it right now with dropdown links but just to convert it to look&feel of tabs whereas by "2nd level" I mean to have the following tabs:

• Submissions
• Download
• Clear (up to here are the own webform tabs)
• Submission view A (these and all the below are the views that are enabled as submission views)
• Submission view B

As the views can be injected on multiple routes, the 1st part of the tabs (the "webform own" tabs as I called them) would vary depending on the current route but still the logic stays the same: display "webform own" tabs whatever they are and then append the submission views tabs, if any, for the current route.

To be honest I prefer to append to the 2nd level because having 3 levels of tabs sounds like a little bit confusing to me but I do not insist on my preference since I am not a UX expert :)

Both options can be supported. Right now only the dropdown is supported via the UI. Adding additional tabs requires some custom code.

I agree with the approach from #48. Ideally, the Views related tabs would appear after the 'Submissions' tab.

I am going to commit this patch now.

Yes, I'll be tagging the next release next week.