Skip to content
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

Closed
smith opened this issue Sep 9, 2022 · 7 comments · Fixed by #145935
Closed

[Infrastructure UI] Predefined host filtering controls #140445

smith opened this issue Sep 9, 2022 · 7 comments · Fixed by #145935
Assignees
Labels
Epic: Host Observability Feature:Metrics UI Metrics UI feature Team:Infra Monitoring UI - DEPRECATED DEPRECATED - Label for the Infra Monitoring UI team. Use Team:obs-ux-infra_services

Comments

@smith
Copy link
Contributor

smith commented Sep 9, 2022

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

CleanShot 2022-09-14 at 15 42 47@2x

Dashboard example

CleanShot 2022-09-14 at 15 46 43@2x

✔️ Acceptance criteria

  • Controls are shown after the search bar:
    • Operating System
    • Cloud provider
  • Selecting items from these dropdown controls filters the list of hosts.
  • Updates the URL state
@botelastic botelastic bot added the needs-team Issues missing a team label label Sep 9, 2022
@bhavyarm bhavyarm added the Team:Infra Monitoring UI - DEPRECATED DEPRECATED - Label for the Infra Monitoring UI team. Use Team:obs-ux-infra_services label Sep 9, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Sep 9, 2022
@ThomThomson
Copy link
Contributor

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.

@smith
Copy link
Contributor Author

smith commented Sep 12, 2022

Updated the issue description to talk about the controls API after speaking with @ThomThomson.

@neptunian neptunian changed the title Predefined host filtering controls [Infrastructure UI] Predefined host filtering controls Sep 22, 2022
@jennypavlova jennypavlova self-assigned this Nov 16, 2022
@jennypavlova
Copy link
Member

jennypavlova commented Nov 16, 2022

@smith @ThomThomson Thank you for the information!
I checked the Controls plugin and I have some questions:

  • Can we use the controls with the embeddable service and do we have an example of how to use them?
  • If we can use the embeddable plugin do we need to enable the controls bundle in the requiredBundles ( I saw the way we are create is used in the dashboard but I am not sure that's what we need here)
  • 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?

EDIT: P.S. To make it easier I added my questions related to the ControlGroupInput directly on a branch with hard-coded data (The code there is not showing the controls correctly - I see the error Uncaught Error: requires type and id)
So it's just about the questions in the code comments because I couldn't figure out which id, type, field, etc. I should use and maybe that's the reason I see this error. 🤔 ( Also any feedback is much appreciated 🙂 I want to know if I am going in to the right direction there and what I am missing )

@ThomThomson
Copy link
Contributor

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?
There is currently, unfortunately, no example plugin or any examples on the usage of the Controls. We have an issue defined for adding examples, but we haven't quite gotten there yet. Before the examples are finished, it's easiest for us to hop on a call to discuss how it all works.

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 src/plugins/controls/public/control_group/control_group_renderer.tsx which you can grab via LazyControlGroupRenderer directly in the controls plugin's public directory.

If we can use the embeddable plugin do we need to enable the controls bundle in the requiredBundles?
Yes, you will need to add the controls bundle to your requiredBundles. It's a little annoying, but we still need to go through the plugin API!

How do we define static options like in the screenshot? Do we have any examples?
Again, unfortunately, there are no examples at the moment, but your branch is going about it roughly the right way. We will be enhancing the API to make this easier, but in the meantime it will look very similar to how you've done it, just with a few small changes to get them up and running.

Should we update the controls once we change the unified search filters/query?
Yupp! Once I show you how to use the Control Group API which is returned by the renderer, this will become quite a bit easier. You just have to subscribe to your unified search bar's state change and push its state to the Control Group.

In short, you are going in the right direction, with a few modifications which we'll make in our meeting tomorrow.

@jennypavlova
Copy link
Member

Hi @smith @ThomThomson,
I described some issues I faced with the last point of the AC (Updates the URL state) in the first PR. The issue is mostly related to prefilling the control group panels from the url (if we persist the filters in the url state) as it's not currently supported by the Controls API. I also added a section with the things I tried and ideas we had with @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 )
What do you think?

@ThomThomson
Copy link
Contributor

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.

@jennypavlova
Copy link
Member

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.
As I mentioned in this PR's description we can't prefill all kinds of filters with the currently supported selectedOptions type.

@smith I added a new issue in our backlog for implementing that when the Control API change is ready

jennypavlova added a commit that referenced this issue Nov 30, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Epic: Host Observability Feature:Metrics UI Metrics UI feature Team:Infra Monitoring UI - DEPRECATED DEPRECATED - Label for the Infra Monitoring UI team. Use Team:obs-ux-infra_services
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants