-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GS providers improvements #75174
GS providers improvements #75174
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -25,7 +25,7 @@ export const createSavedObjectsResultProvider = (): GlobalSearchResultProvider = | |
const responsePromise = client.find({ | ||
page: 1, | ||
perPage: maxResults, | ||
search: term, | ||
search: term ? `${term}*` : undefined, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there any issue with using Ideally, we'd be boosting results where the beginning of the field matches the search term, probably using multiple There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yea, I'm not really sure. Without proper boost, searching anywhere in the field can have some unexpected behavior in term of results. I feel like until we are able to construct a more precise search dsl, prefix-only may be better. @ryankeairns WDYT? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I’m happy with the prefix-only change for now and collecting more feedback post-merge/release. |
||
preference, | ||
searchFields, | ||
type: searchableTypes.map((type) => type.name), | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getAppInfo
now computes the navlink status as it was more or less done inkibana/src/core/public/chrome/nav_links/to_nav_link.ts
Lines 38 to 41 in 0247df4
As
AppServiceStart.applications$
is a public API that is supposed to return the computed state of the apps, I think it make sense, instead of letting the consumers manually apply this logic.