Allow more control over how new filters are added to the filter bar

[Bargs]

Related to #14104

Currently a click or brush on a visualization will always create a new filter pill which is combined with existing filters with an AND. Instead of adding a new filter users often just want to add another optional value to an existing is one of filter. This need becomes particularly acute when input controls are in use because there's currently no way to combine a filter created via a visualization with the filters controlled by the input controls. The input controls try to get around this by automatically merging all filters for the target field but we're getting rid of that to solve #14104.

So to give users more control over how new filters are added to the filter bar we're considering adding a modal that will pop up whenever you create a filter that targets the same field as an existing filter. It will give you the option to create a new filter or merge it with an existing one. Below is a rough sketch of what we're thinking.

[trevan]

It would also be nice to negate and remove filters as well. Clicking on graphs will sometimes add multiple filters. Some of those filters, you don't actually want (in my case, I usually remove the time filter but have also removed "higher" filters). Some of the filters you want negated. Right now, they go to the top of the screen which requires you to scroll back up to the top, remove the items, run the search, negate the item, re-run the search. Having it in a pop up before it goes into affect would simplify the workflow and reduce the load on elasticsearch.

[ddrake17]

+1 for this issue.

I also agree about having an apply dialog where ever the user is in the screen although that sounds like it belongs on a different issue.

[markharwood]

We have a more fundamental issue here.
We always assume with filters that we are ANDing filters with any free-text input that may exist in the Lucene/KQL bar. This is a false assumption.
As an example, If I'm searching github commits relating to GIS I may start with a free-text query, "maps". I might look at the results of significant_terms analysis on the structured dirs field to find directories in the repo with a high-concentration of these types of commits e.g, the maps and gis directories. In Sculptor that discovery would look like this:

Having selected the gis and maps directories I would then drag these selections alongside the free-text query to make ORs:

So now we match commits that say explicitly in the commit message they are something to do with "maps" OR are implicitly something to do with maps because they are making changes in key directories that we established are associated with maps functionality.

There's often more than one way of saying something so ORing structured criteria with unstructured criteria is a basic requirement of a query/filter builder.

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[ppisljar]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.