[RAC][Alert Triage] Alerts Table Component

[spong]

Description

This issue is for the generification of the Alerts Table component used within the Alert Triage workflow on the main Security Detections page and Rule Details page.

As used within the Observability mocks:

Interface

Inputs

• Page-level KQL query, filters, and daterange
• .alerts index to query against
• Alert Actions
  • Array of actions w/ underlying alert as context
  • Number of actions to display before overflowing
  • Alert details component provider

Outputs

• Page-level KQL query, filters, and daterange

API Requirements

• Generic query API for fetching documents from the .alerts index. Currently implementation is all handled server side, and takes index and query and timeline magic handles the rest 🙂

Destination Plugin/Package 🏠

• Most likely dedicated timeline plugin/package, but TBD

Feature Extension

• UtilityBar to be integrated directly within EventsViewer
• Ability to specify Alert Details component provider for rendering custom view in Alert Details
• Removal of Status/Additional Filters component (will be created as dedicated component)

Existing Source

Table wrapper, including utility bar, actions, and default configuration (columns, sort, etc) located here. Underlying table implemented as StatefulEventsViewer.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[katrin-freihofner]

There are a couple of things that I hope we can improve on this table as we move to a shared component. I ordered them according to what I think of as the highest priority. cc @lindseypoli @mdefazio

1. Table actions
   I don't think that these icon buttons are self-explaining. I even wonder if we could apply the same UX as we already established in EUI data grid.

2. Row icon buttons
   These buttons are not self-explaining. In my opinion, it is not clear where to click and what these buttons mean. Also, in Observability, we will only need the details and context menu buttons for now, so this might not be an issue.

3. Accessibility: Keyboard navigation
   In my opinion, we need a couple of improvements to make the table and row action buttons and pagination accessible via keyboard.

4. Select the number of rows
   A user selects a number of rows for a reason. Therefore, I suggest not restricting the height of the container in this case and showing the selected number of rows.
   

5. Severity indicator
   In Observability we probably want a additional visual indicator for severity instead of text only. cc @cyrille-leclerc

Something like the EUI health badge

6. In my opinion, responsive behavior is part of a high-quality UI. I also think it is especially important for these views as they are used for troubleshooting. This can happen anywhere, anytime, and on any device.

7. There is a small bug with the background on this actions menu.
   

8. Tooltips appear too slow
   In my opinion, there is too much delay when tooltips appear.

[mdefazio]

Great points @katrin-freihofner , thanks for putting this together. In regards to your 1st point, are there downsides to switching to the EuiDatagrid? Perhaps doing so solves a few of these issues right out of the box (accessibility, responsiveness). Or do we simply take the Datagrid control bar and place it above the table?

[elasticmachine]

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

[sorenlouv]

are there downsides to switching to the EuiDatagrid? Perhaps doing so solves a few of these issues right out of the box (accessibility, responsiveness). Or do we simply take the Datagrid control bar and place it above the table?

Switching to the EuiDatagrid sounds like a good idea. I agree that it'll most likely solve the accessibility issues.

[tsg]

We definitely want to adopt the EuiDatagrid, we're just waiting for it to be ready. We have actually evaluated switching a few times already but there were missing capabilities. From what I understand, the main thing holding us now is support for variable-height rows, but when that is supported, we'll be most happy to switch.

Thank you for the review @katrin-freihofner, perhaps we can work together to solve some of these.

[peluja1012]

Implemented by #103270