Views integration: filter

Hello,

Here are my investigations on the Webform module.

Webform has "basic" Views integration. Only base fields on the webform submission content entity are handled.

To have deeper Views integration, the https://www.drupal.org/project/webform_views module is required.

Also, a webform will use Views only if set on /admin/structure/webform/manage/[WEBFORM_ID]/settings/submissions, in the fieldset "SUBMISSION VIEWS SETTINGS".

Enable the webform_test module and go to /admin/structure/webform/manage/test_submission_views/settings/submissions to see an example.

This Views integration is ok with some "basic" filters and fields. See the Webform Views module page to have a list of supported field types.

How Webform stores data?

With a dedicated content entity: webform_submission. But the fields are not properly fields, like base fields or fields added using the field API / Field UI.

Data is handled manually.

In src/WebformSubmissionStorageSchema.php::getEntitySchema() the webform_submission_data table is declared.
In src/WebformSubmissionStorage.php, the data is inserted in the table in the saveData() method and injected into the content entity in the loadData() method.

In webform_submission_data, there is a "property" column to store the element identifier in case of a composite element. This can be useful for the value and end_value for the date range plugin.

I have not found/searched deeply why Webform "// Delete existing submission data rows." before inserting current values.
I think it is because it is easier that way to avoid side effects or because it was impossible to use a merge tu update existing values.

A solution to try is to:
- create a custom table inspired by the webform_submission_data
- in the EVP field type, implements a postSave() method to populate this new table
- I think this would require an additional method on the plugin interface.
- Add Views filters/sorts plugins (easier to write than to do...):
- need to loop on all EVP field instances to declare filters and sorts
- should we check the field instance to see which plugins are enabled?
- for each plugin declare the corresponding filters and sorts
- maybe only adds plugins implementing a certain method or a sub-interface to be able to distinguish between Views compatible plugin and the other ones.
- filters and sorts plugins could be declared separately from the EVP plugin system.
Even though, if we had additional methods to the plugin interface, that would force each plugin
to be Views compatible. And maybe for some plugins it will be impossible to be Views compatible so no need to force the compatibility.
- implements a filter and sort class per plugin.

The custom table structure would be something like this (can be discussed obviously):
- entity_type_id
- entity_bundle?
- field_machine_name
- entity_id
- revision_id
- langcode
- property
- delta
- value

Also, if this solution is a success, this will avoid to have to rewrite the whole module...

Hello @NightAr,

Are you still working on this issue?

Do you need help on it?

Can you please upload a patch or create a fork and push your work on it? Even if it is not working so we can have some feedbacks of what the difficulties are.

Thanks! :)