[Fleet] Results are not being filtered out properly when using a random word on search bar of Agent Policies tab.

[ghost]

Kibana version: 7.14 BC-3 Kibana cloud environment

Host OS and Browser version: All, All

Preconditions:

1. 7.14.0 BC-3 Kibana cloud environment should be available.
2. Default or newly created policy should exist.

Build Details:

Build: 42545
Commit: c314921a9893e0b46d9a3958f5520e3d6b1ce7d5

Steps to reproduce:

1. Login to Kibana.
2. Navigate to Fleet-> Agent Policies tab.
3. Search for any random policy value(let say : xyz ) in Search field.
4. Observe that results are not being filtered out properly.

Actual Result
Results are not being filtered out properly when using a random word on search bar of Agent Policies tab.

Expected Result
Results should filtered out properly when using a random word on search bar of Agent Policies tab.

OR

Message like "No agent policies found. Clear filters" is displayed when we search policies with any random value under Agent Policies tab.

What's working

• This issue is not occurring on Other tab like : Agents, Enrollment tokens, Data streams.

Agents

Agents.-.Fleet.-.Elastic.mp4

enrollment tokens

Enrollment.tokens.-.Fleet.-.Elastic.mp4

Data streams.

Data.streams.-.Fleet.-.Elastic.mp4

What's not working
N/A

Screen recording

Agent.policies.-.Fleet.-.Elastic.mp4

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[ghost]

@manishgupta-qasource : Please review the Bug.

[manishgupta-qasource]

Reviewed & Assigned to @jen-huang

CC: @EricDavisX

[hop-dev]

TLDR: searching for agent policies without specifying a key e.g "aaa" returns a 400, think we need to add something that adds a key in the backend?

@jen-huang @kpollich I could do with a bit of a steer on this one, I think we need to add search behaviour for agent policies when no key is provided.

The issue is that when searching for a simple string, "aaa" in the search box, we are getting a 400 response back from the API, originating from the saved objects client:

{"statusCode":400,"error":"Bad Request","message":"The key is empty and needs to be wrapped by a saved object type like ingest-agent-policies: Bad Request"}

I find that strange because KQL appears to support this keyless syntax (https://www.elastic.co/guide/en/kibana/current/kuery-query.html#_terms_query), so this is maybe a restriction we have when specifically looking up saved objects?

When looking up agents in the adjacent tab, not providing a key works fine, this is converted to a multi match best fields query e.g "aaa" results in:

{"multi_match":{"type":"best_fields","query":"aaa","lenient":true}}]}}

My instinct was that we could have the agent policies behaviour be to search over name and description, so if there is no ":" in the kuery e.g "aaa" then it would be converted to something like "ingest-agent-policies.name : aa or ingest-agent-policies.description : aa" but I may be missing something obvious

[kpollich]

Thanks for digging into this @hop-dev. After clicking around the tables and observing based on your notes, I am seeing the same behavior and issue. The Agent Policy table throws a 400 on every keystroke when no field is specified for the search.

Here's where the kuery query parameter is handled on the server side for the agent policy search requests:

kibana/x-pack/plugins/fleet/server/services/agent_policy.ts

Line 329 in eaa6dcb

filter: kuery ? normalizeKuery(SAVED_OBJECT_TYPE, kuery) : undefined,

And here are some examples of how it's handled for other resources, namely Enrollment Keys and Agents:

kibana/x-pack/plugins/fleet/server/services/api_keys/enrollment_api_key.ts

Lines 37 to 38 in eaa6dcb

	const query =
	options.query ?? (kuery && esKuery.toElasticsearchQuery(esKuery.fromKueryExpression(kuery)));

kibana/x-pack/plugins/fleet/server/services/agents/crud.ts

Line 121 in eaa6dcb

const body = kueryNode ? { query: esKuery.toElasticsearchQuery(kueryNode) } : {};

It seems like maybe we need this .toElasticsearchQuery helper in our Agent Policy API handler. I'm not super familiar with everything here, but maybe this can be helpful in landing on a solution.