-
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
[Infrastructure UI] Predefined host filtering controls #140445
Comments
Thanks for making this issue @smith ! One thing - currently, selecting items from the Controls does not add filters to the filter bar. This is so that filters from the bar can affect the what shows up in the Controls. You can apply filters to your page context without them needing to appear in the filter bar! We could configure it to work either way, if the use case requires it, but it's best to keep the consistency. |
Updated the issue description to talk about the controls API after speaking with @ThomThomson. |
@smith @ThomThomson Thank you for the information!
EDIT: P.S. To make it easier I added my questions related to the |
Hi @jennypavlova! I really thought I had responded to this earlier, but I guess I just wrote out my answers and didn't hit send, sorry about that! Can we use the controls with the embeddable service and do we have an example of how to use them? You can use the Controls like you've done in your example branch, but there is actually an easier way which is more inline with how we are planning on offering these in the future, using the strongly typed react component that we're exposing in If we can use the embeddable plugin do we need to enable the controls bundle in the requiredBundles? How do we define static options like in the screenshot? Do we have any examples? Should we update the controls once we change the unified search filters/query? In short, you are going in the right direction, with a few modifications which we'll make in our meeting tomorrow. |
Hi @smith @ThomThomson, We can maybe first have the PR reviewed and when we have the possibility to prefill the control group panels from the url filters to continue with the url state implementation ( I added a separate branch to try some ideas ) |
It seems like we'll need to change up our API to properly support the use case of keeping the Control state in the URL. This is something we've already had some preliminary discussions on and are working towards consensus on an approach. Take a look at this issue comment for some of our thoughts. It's of course up to you, the consumer, whether you'd like to wait for the API support, or if you'd like to implement the code yourself then upgrade to the new system once it becomes available. |
@ThomThomson Thank you for the reply! I think the better option will be to open another issue which can be picked once Controls API changes are implemented on your side. @smith I added a new issue in our backlog for implementing that when the Control API change is ready |
Closes [#140445](#140445) ## Summary This PR adds 2 filters (Operating System and Cloud Provider) using [Kibana Controls API](https://github.com/elastic/kibana/tree/main/src/plugins/controls) to the Host view. ## Testing - Open Host View - The Operating System and Cloud Provider filters should be visible under the search bar. Supported values: - Filter Include/exclude OS name / Cloud Provider name - Exist / Does not exist - Any (also when clearing the filters) - The control filters should update the possible values when the other control filter or unified search query/filters are changes - When the control group filters are updated the table is loading the filtered result. - Combination with unified search query/filters should be possible. ![image](https://user-images.githubusercontent.com/14139027/203373557-f9220f22-53ee-4fe0-9bdd-cdc08ce31156.png) - Copy the url after adding the filters and paste it into a separate tab - The control group AND the other filters/query should be prefilled ## 🎉 UPDATE the control panels are prefilled from the URL ### The Workaround: Together with @ThomThomson we found a way to prefill the control group selections from the URL state by adding the panels' objects to the URL state (using a separate key to avoid the infinite loop issue) and keeping the output filters (used for updating the table) separately. ## Discovered issues with persisting the new filters to the URL state ~~⚠️ This PR does not support persisting those filters in the URL state. The reason behind this is that if we persist those filters inside the other filters parameter it will create an infinite loop (as those controls are relying on the filters to adjust the possible values).~~ In order to avoid that we can persist them in a different parameter (instead of adding them to the existing `_a` we can add a new one for example named `controlFilters`. This will work with filtering the table results. BUT If we go with the solution to persist them in another `urlStateKey` we also need to prefill those selections from the url state to the control filters (Operating System and Cloud Provide). Currently, the controls API supports setting `selectedOptions` as a string array. ### Workaraound Ideas Option 1: I tried first on a[ separate branch ](main...jennypavlova:kibana:140445-host-filtering-controls-with-url-state) - Persist the filters as an array of filter options. - on load prefill the control filters - extract the string values from the filters and set them as `selectedOptions` inside the control group input `panel` (based on the field name for example) Option 2 (Suggestion from Devon ) - on load pass in the selections from the URL to the control group input - Don't render the table right away - Wait until control group is ready .then - Get the filters from the control group output - Set filters from controls in the use state by doing controls.getOutput().filters - Render the table with ...unifiedSearchFilters, ...filtersFromControls ❌ The issue with both 1 & 2 - With `selectedOptions` we can prefill only **strings** so `Exist` and `Negate` won't be supported
Allow hosts in the hosts view to be filtered using some predefined controls.
How
Use the Kibana Controls API to show these below the filter bar. Set some time up to pair with @ThomThomson, as the documentation for this API is not yet in place.
Future considerations
This is a first pass that will give us an easy way to see what the platform can provide in terms of easy-to-use filtering. If users find this kind of filtering useful, we can later see what ways it can be expanded.
Eventually we could show tags and attributes to filter on based on some discovery of which things are available and relevant to the data you're looking at, as well as providing customization, but for now we can start with these static options.
Mockup
Dashboard example
✔️ Acceptance criteria
The text was updated successfully, but these errors were encountered: