Saved object full text search experience does not meet expectations

[rudolf]

There are several places where the Kibana UI allows users to search over their saved objects:

1. Management
   1. Saved objects
   2. Data views
   3. Tags
   4. Cases
2. Dashboard list
3. Visualize library

We have received feedback from users that the search experience does not meet their expectations. There have also been several attempts to solve this each only making it incrementally better. This issue is to discuss how we might provide users with a world class search experience powered by the saved objects APIs.

I suggest the following steps to be able to make progress against this problem:

1. Identify the combination of search query, text analyser and mappings that provide the best possible search experience on the raw Elasticsearch APIs
2. Ensure that it's possible to use the above combination for saved object types using the server-side saved objects client.
3. Create a guide for teams to ensure their saved object types have everything needed to power a powerful search experience and adapt the UI if/where needed.

Related issues:

• Allow wildcard when searching saved objects #9767
• [META] Filtering/searching on tables woes #14729
• add support of wildcard when selecting visualize #97074
• Searching saved objects should match anywhere in object name #32776
• Saved object finder doesn't apply search field correctly #90315
• Search for Saved Searches doesn't find substring #22051
• [Discuss] Enhancement/saved object search #15175
• Searching for saved objects with dashes shows no results #5734
• https://github.com/elastic/enhancements/issues/17002
• [TableListView] Search on listing page does not handle queries with numbers correctly #151007

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[rudolf]

Saved objects currently uses the default analyser and constructs a "simple query string" query from the user's input. Both of these have limitations that limit the power we can expose to users.

[pgayvallet]

and constructs a "simple query string" query

Probably worth mentioning that we're also supporting 'startWith' queries by detecting if the * wildcard is present at the end of the search query and then add an additional match_phrase_prefix close in addition to the SQS (see #82693)

We have received feedback from users that the search experience does not meet their expectations

First thing here would probably be to identify what those expectation are, as it's still unclear to me by just looking at the issue's description.

Looking at the linked issues, it seems like most of the problem is the inability to search parts of a token/word (basically, being able to use the * wildcard anywhere in a token) for searches.

Is that correct? Is this what we should be focusing on? Or are there other expectations that aren't met by the current search logic?