-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Filtering actions on alerts without any actions #58362
Comments
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
Does it make sense to have the filter dropdown only list the currently used action types? So in the case above, there would only be Slack in the dropdown. We could probably go a step further and have that be disabled or preselected, or something, since it wouldn't actually change anything. This way we can avoid an empty state altogether. |
I can imagine a situation where I might want to "confirm" that no alerts are using some particular action/actionType, which would be a case where I'd want to see an empty state (if empty state means the list is empty). |
I think on our sync yesterday, it seemed like having an additional filter of "has no actions" along with the other filters would work. Presumably can be multi-selected with other filters. So you could filter on "email" or "has no actions" - not that it would make a lot of sense, but would avoid having to special case a search on "no actions". |
Maybe it makes sense to have a filter on the Connector tab that is 'has no alert' to help solve this use case. |
Would an alert have no actions because I deleted an action that it was using? Wouldn't this be returning an error of some sort then? |
You could have a scenario where a customer has an alert with an action, and decides to replace the existing action with another. They would likely delete the existing one, and then add the new one. Imagine they got interrupted after deleting the existing one, before adding the new one (even though both operations could be done together, atomically, since it's just modifying the actions structure in the alert structure). The alert would then be in a state with no actions. I imagine there may be some other scenarios where someone may want to delete an action in an alert if the alert was being annoying or something. Even though there are other ways they could "mute" the alert, deleting the action may be the first thing that comes to mind, and I think we should certainly allow it. I'd be pretty frustrated as a customer if I couldn't delete an action on an alert because of a constraint that we imposed that every alert must have at least one action. And there are the current SIEM alerts, which (right now) have no actions associated with them. :-) |
As mentioned in #58493, I've updated the filter dropdowns to help avoid the empty state, add added an extra filter option when no alert has an action assigned to it I'm also attaching a mockup for an empty state since we need one regardless of the above. |
As I'm working through license checks (#54946). I'm wondering what the action type filter would look like in the following two scenarios?
Both of those may have alerts or connectors assigned to them if ever they were created before the action type got disabled. Currently we can easily tell in the connectors list how many connectors use an action type. We currently don't know in the alerts list how many because it is tricky to aggregate. The main reasons are due to feature controls / security not applying to aggregation queries (for now). |
So if I understand the last comment, we can show a filter menu for the connector table that is pared down based on the action types used, but we can't on the alerting tab. Is it a total count that is difficult, or if its used at all? |
@mdefazio that correct and we can't on the alerting tab because we can't easily tell if an action type is used at all. With the feature controls work we're planning to do, we may be able to revisit that answer later. |
So the above screens work for the connector tab? Where the thinking is that we show a type if there is a connector of that type, even if it's disabled (assuming its still visible in the table to the user). Otherwise the type would be disabled in the filter menu. So then for 7.7 for the alerting table, we just show all action types in the filter menu? And we need the empty state for when there are no alerts with that type. |
That's correct
That's correct
This piece we won't be able to do for now due to not knowing how many alerts use that type. |
Not sure if the discussion was resolved around a disabled action type? Do we show action types in the filter menu if the user does not have access/disabled? Also, might not be for this issue, but a few thoughts if we are closing this.
|
It looks like they still show up in the filter menu if they are disabled. Based on this comment it seems like that was the expected behavior (at least for 7.7). Have there been changes since 7.7 that would allows us to remove them from the filter menu if they are disabled? |
Closing this as the original issue (no empty state when filtering rules) has been addressed. Created follow up issue for additional UX improvements to the action type filter: #101597 |
Steps to reproduce:
I think we need another empty state that says "nothing matches filters" or something along those lines. I imagine we have a common empty state for a filtered list view, right?
cc: @mdefazio
The text was updated successfully, but these errors were encountered: