In practice, when the finder can potential displays a lot of objects, it can cause issues if the current page is not displaying all types of possible results.
E.g if the finder is configured to display vis, dashboard and search types, and if the current page of results only displays objects of the vis type, both dashboard and search will be disabled from the type filter.
This decision was probably made only with the scenario where the user first filters results via the search bar, and then limit the type of results via the filters. The other way around (first filtering by type, then filtering by query) does not work because of this limitation.
I think we should just remove this disabled logic altogether (which would get closer to the behavior we have for the SOM searchbar anyway)
The
SavedObjectFinder
client-side component disables types that are not present in current results from thetype
filterItems from the context menu are disabled with this condition:
https://github.com/elastic/kibana/blob/f1ea4794e6b0f57199f0af0eb567e9f4530bce97/src/plugins/saved_objects/public/finder/saved_object_finder.tsx#L416-L418
With this
availableSavedObjectMetaData
state coming from:https://github.com/elastic/kibana/blob/f1ea4794e6b0f57199f0af0eb567e9f4530bce97/src/plugins/saved_objects/public/finder/saved_object_finder.tsx#L267-L273
In practice, when the finder can potential displays a lot of objects, it can cause issues if the current page is not displaying all types of possible results.
E.g if the finder is configured to display
vis
,dashboard
andsearch
types, and if the current page of results only displays objects of thevis
type, bothdashboard
andsearch
will be disabled from thetype
filter.This decision was probably made only with the scenario where the user first filters results via the search bar, and then limit the type of results via the filters. The other way around (first filtering by type, then filtering by query) does not work because of this limitation.
I think we should just remove this
disabled
logic altogether (which would get closer to the behavior we have for the SOM searchbar anyway)