Fixes auto suggest in security solution

[stephmilovic]

Resolves #144229

Security solution does store the full DataView object on the client side of the siem app for performance reasons. The addition of the line return indexPattern instance of DataView to unified search breaks auto suggest kql query bar across all of security solution. By changing the check to only check for the necessary property indexPattern.fields, everything functions as expected again.

• Fixes auto suggest bug
• Adds a cypress test in security solution to confirm the fix

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[stratoula]

This change looks good to me, @lukasolson wdyt?

[MadameSheema]

Thanks Steph!! The test added LGTM. Just left a couple of nit comments.

[lukasolson]

Hmm, just from a quick check of the autocomplete logic it looks like we need to make sure the data view object has other fields as well, such as title and timeFieldName (and possibly others). What is the data view in security solution an instance of? Maybe for now we could at least check for title as well. @mattkime Any thoughts on how to verify that the object here is data view-like?

[mattkime]

I’d prefer to move away from using data view like objects. Perhaps security solution could create an ad hoc data view and skip loading the field list.

that said, I know that this need to ship quickly and I don’t want to slow this down

[stephmilovic]

I’d prefer to move away from using data view like objects. Perhaps security solution could create an ad hoc data view and skip loading the field list.

@mattkime @lukasolson
we already have the field list. all that we have is fields and title. We do not have timeFieldName, wondering if we need to require that? if not passed, we can default to @timestamp

[dhurley14]

@lukasolson @mattkime I briefly mention some complexity issues here. I think there is definitely an interest in moving as much of sourcerer to use ad-hoc data views as possible, as is the case with the effort in this draft PR by @YulNaumenko . However, after spending some time investigating how we could implement in-memory data views in sourcerer before reaching out to @mattkime, it became apparent that we would not have the time to implement these changes in sourcerer. At this stage of the release process I am afraid the necessary changes to accomplish a move to in-memory data views for sourcerer will introduce too many changes to the security solution and we will not have the capacity and requisite time to cover all edge cases where code depending on properties from the SourcererDataView type will need to be migrated to corresponding properties on the DataView class. I think the ask here is if it is possible to reduce the partitioning logic such that it is only checking for properties the unified search bar requires to function?

[stephmilovic]

Just found/fixed this related bug. Thinking we should check for type and value properties as well?

FWIW, from what I can tell value is not even on the DataView class that unified search is checking:

return indexPattern instanceof KibanaDataView

[stratoula]

From Lukas' comment I understand that title and fields is sufficient. I would really like to understand why this doesn't work on security solution, is the dataviews not an instance of KibanaDataview?

I am approving as I understand it is a significant bug!

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: cb6f7da

Failed CI Steps

• Security Solution Tests #4

Test Failures

• [job] [logs] Security Solution Tests #4 / All exception lists - read only "before all" hook for "Displays missing privileges primary callout"

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
unifiedSearch	216.1KB	216.2KB	+20.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
unifiedSearch	50.7KB	50.5KB	-140.0B

Unknown metric groups

ESLint disabled in files

id	before	after	diff
osquery	1	2	+1

ESLint disabled line counts

id	before	after	diff
enterpriseSearch	19	21	+2
fleet	59	65	+6
osquery	109	115	+6
securitySolution	442	448	+6
total			+20

Total ESLint disabled count

id	before	after	diff
enterpriseSearch	20	22	+2
fleet	68	74	+6
osquery	110	117	+7
securitySolution	519	525	+6
total			+21

History

• 💚 Build #90451 succeeded e142aad
• 💛 Build #90143 was flaky 0040ea4
• 💚 Build #89821 succeeded 1becd7a

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.6

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation