Dashboard/Visualization search needs to be able to keep best match criteria

[JacobBrandt]

In previous Kibana versions (5.3) the search for these two pages would basically give you a best match on Elasticsearch's scoring criteria for the search term. We upgraded to 5.6 and now the results are always being sorted without a way to turn the sorting off.

Describe a specific use case:
Say for instance a Dashboard was named "Test - Zones". The "Test - A", "Test - B", "Test - C", etc. dashboard names would show up first because of the automatic sorting being applied making the search unusable when you have hundreds of similar named visualizations/dashboards.

I got around this by modifying our current version to show the best match Elasticsearch provided on the search term.

[nreese]

This has been addressed in the Dashboard application for 6.4 with PR 16967 and PR 17374

[JacobBrandt]

It turns out I was mistaken on my assessment of how 5.3 returned results. The real problem is that 5.3 did an 'AND' for the simple query string default_operator parameter and 5.6 uses the Elasticsearch default of 'OR'.

[bmcconaghy]

This looks to be resolved. Please reopen if needed.

[JacobBrandt]

@bmcconaghy In case anyone wants to know this was not resolved and I am not allowed to reopen. 6.5 still uses Elasticsearch's default value of OR for the default_operator field and does not set it to AND like it did in previous versions of Kibana when searching for dashboards or visualizations. I'll explain why this is a problem.

Take names like:

• it takes two to make a thing go right
• one two three
• there can be only one
• three strikes you're out

5.3 and previous versions would return the following for the search: one two three

• one two three

Everything after 5.3 would return the following for the search: one two three

• it takes two to make a thing go right
• one two three
• there can be only one
• three strikes you're out

So even though you wanted to search for the specific dashboard name you are returned with every dashboard/visualization that has the name one OR two Or three. With thousands of visualizations and hundreds of dashboards this kind of searching is not helpful. Depending on what our users would type in they might not even see their dashboard they were trying to look for on the first page. A configurable setting or even a toggleable radio that switches between the two default operators to use for spaces on the fly would be appreciated so we can get back to previous behavior when searching for saved objects.

For reference:
5.3
https://github.com/elastic/kibana/blob/5.3/src/ui/public/courier/saved_object/saved_object_loader.js#L87

Everything after 5.3 including master does not set default_operator to AND when searching for saved objects.

[nreese]

Have you tried the query one+two+three, that should force the AND operation.

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-simple-query-string-query.html#_simple_query_string_syntax

[JacobBrandt]

I didn't know that operator would work. Yes that would force the AND operation but was this an intentional change to the saved objects searching from previous versions? If so, I'm curious as to what drove this decision. I think the previous behavior makes more sense as you are 9 times out of 10 trying to find the one occurrence of a saved object. Which I think makes AND the more suitable default operator when searching like it has been for long time.

The current default searching (for a basic search) of saved objects is now search any occurrence of the terms provided with relevance thrown out the window because results are shown alphabetically. I believe this makes the searching cumbersome.

[nreese]

was this an intentional change to the saved objects searching from previous versions? If so, I'm curious as to what drove this decision. I think the previous behavior makes more sense as you are 9 times out of 10 trying to find the one occurrence of a saved object. Which I think makes AND the more suitable default operator when searching like it has been for long time.

@stacey-gammon I am trying to track down why saved object loader switched from setting simple_query_string.default_operator: 'AND' (until Kibana 5.6).

It looks like Use saved object client for saved_object_loader find function modified the saved object loader from directly calling elasticsearch to calling /api/saved_objects/_find. This PR modified how simple_query_string.default_operator is getting set. The implementation of /api/saved_objects/_find does not set simple_query_string.default_operator when making the request to elasticsearch. Was switching default_operator from AND to OR an intentional behavior change? If so, can you explain why the change?

[stacey-gammon]

It was awhile ago, but I don't believe the change was intentional to not use and, but rather to be consistent with the saved object _find endpoint so all search tables should, theoretically, act the same. These tables though have quite a few inconsistencies and issues, most listed in this META issue: #14729.

cc @tylersmalley - does the saved object client support switching to an and default operator? Has there been any discussion about making that the default?

[tylersmalley]

@stacey-gammon it does not currently support changing the operator (implemented here: https://github.com/elastic/kibana/blob/master/src/server/saved_objects/service/lib/search_dsl/query_params.js#L117)

I don't think changing this behavior was intentional.

[timroes]

I'll close that as a duplicate, since it seems to be covered by two other issues: The fact that the saved object API nowadays searches by OR instead of AND is covered by #20676. Another issue is, that the visualization page is always sorting alphabetically even when searched, and not using the ES order, which makes more sense for queries. This is tracked in #14687