[RAC] Filter active/recovered status

[mgiota]

📝 Summary

In the Observability alerts table user should have the option to filter by the alert status(kibana.alert.system_status), which can be either active or recovered. This shouldn't be confused with the workflow status (kibana.alert.workflow_status) which can be open, acknowledged, closed

✔️ Acceptance criteria

• add the filter actions to the status column similar to the security solution.
• when page loads the “active” state should already be filtered in.

Depends on #108150

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[mgiota]

I checked current implementation and filter actions are being applied to all columns (whole row), whereas we would like to apply them only to one column, the status column. If we apply them to all columns, then I guess the reason field would be problematic, since it is not analyzed.

@jasonrhodes who should I tag from security team to check if there is already a way to add filter actions per column? I am a bit blocked with broken environment. I can check it out further once my environment is up and running

[jasonrhodes]

I think we need to proceed with applying this to all columns for now and we can circle back on whether it's possible (or useful, even) to have different hover actions per column/cell.

The "reason" field won't be totally problematic in this case because it will filter for the exact reason, which will work since the field is a "keyword" field. It will have issues because some rule types are not indexing the reason, so those alerts will not show up even if their reason matches, but there's nothing we can do there for now.

[mgiota]

@jasonrhodes Ok agree.

I need a clarification, the id we get from the status field at the moment is alert.kibana.status. To my understanding it should be alert.kibana.system_status, right?

Regarding reason there are a couple of bugs at the moment. I am writing them down and we should handle them in another ticket:

• clicking on the filter in button filters by kibana.alert.rule.name instead of kibana.alert.reason
• if I manually type kibana.alert.reason: 'CPU' or just CPU in the urlbar, I don't get any results, which is what I mention in this ticket [Observability RAC]: Search a term in the reason field doesn't seem to work #108177. You say it should work since the field is a "keyword" field, but it doesn't according to the ticket I created. We discussed about that again, but it is still not clear to me what needs to be done to make it work (haven't looked into it though, since I got the impression you are aware of how it should work). I guess it is somehow connected to the first bullet above that is reads from kibana.alert.rule.name. Once above is fixed, this one should be fixed I guess. cc @weltenwort

[weltenwort]

ℹ️ To add some more context: Currently we have constants for both ALERT_STATUS and ALERT_SYSTEM_STATUS. The former is used everywhere across the security, uptime, apm, rule_registry, and observability apps. The latter is not used anywhere yet.

Regarding the reason field, I commented on your other issue. The question becomes whether we want the field to be a keyword or a text.