[Security Solution][Tech debt][Epic] Redesign Security Solution hover/inline actions to make it extensible and reusable across the plugins.

[YulNaumenko]

The problem statement for this issue is about making Security Solution hover/inline actions components reusable and extensible and fit the specific consumer needs without impacting the rest of this actions usage in the other places. (Consumer is the component which display/manage the own set of needed hover actions like data tables, timeline, entity analytics page, etc.)
The goal of this epic is to provide the ability to create, register and use the actions with the ability to render them as the inline or hover UI mode.
We should provide enough flexibility to reuse the actions by any of the consumers.
Current Epic includes the next work items:

Phase 1 (Create CellActions package and use it inside SecuritySolutions)

• Research and the first version of implementing AddToTimeline and CopyTo actions using uiActions registry. [Security Solution][Lens] New trigger actions for chart legends and table cell actions #146779
• Create cell actions component. [Security Solution] Add CellActions (alpha version) component to ui_actions plugin #147434
• Create security actions and register them. Issue and PR [Security Solution] Create Security Solution UI Actions #148434
• Refactor explore page to use CellActions [145663] Refactor explore pages to migrate HoverActions to CellActions #148056
• Refactor Alerts page to use CellActions. Existing issue [Security Solution] Replace HoverActions component and useHoverActions hook with the new CellActions for events viewer(alerts and events tables). #145666
  • Move the CellActions implementation to a package. PR: [Security Solution] [CellActions] Move to a package #149057
  • We need to export cell actions as array to be passed to the EuiDataGrid column cellActions prop [Security Solution] integrate CellActions in Events/Alerts DataTables #149934
  • Allow show top n action to render inside another popover on Alerts table
• Refactor Dashboard pages to use CellActions [Security Solutions] Migrate security inline actions to CellActions #149120
• [Security Solution] Finish HoverActions migration to new CellActions #181849
• [blocked by drag-and-drop] Refactor Host/Network/User details flyout to use CellActions
  • Refactor inline hover actions components to use CellActions (it has a different design)
  • Don’t display add to timeline on pages without timeline
• Extract execute and isCompatible into small helper functions (maybe not needed now since using createCellActionFactory the action files are pretty small)
• Move cell actions to a package because now we can import plugins types. Issue [Security Solution] Build a package for CellActions component. #145663
• Move filterIn, filterOut and copy to a package? [Security Solution] Add FilterIn/FilterFor, FilterOut, Copy actions buttons as a packages. #145657
• Update how we create actions
  • Now we can register the action definition object directly according to the comment
• Add support for telemetry (We need to track which actions are triggered from which page).

Tech Debt

• Refactor ShowTopN Action so it doesn’t depend on App context providers [Security Solution] Refactor ShowTopN Action so it doesn’t depend on App context providers #161550
• (afterAll SecuritySolutions pages are using CellActions) HoverActions dead code cleaning
• Rewrite actions to support multiple fields and use them on the investigation in timeline (.andFilters) Update Security Cell actions and default Cell actions to support multiple fields #159480
• [Research] Consider FieldSpec type for the entire DataViewField, so we would be able to use getters such as filterable, displayName
• Update Events/alerts table to provide CellActions with a complete FieldSpecobject from DataView [Security Solutions] Update Events/alerts table to use FieldSpec for CellActions #161361

Bugs

• Fix CellActions component should hide ShowTopN action for nested fields #150347 using subType from fieldSpec
• [FOWARDED to sourcerer team] Fix [Security Solution] Disable filter cellActions for unmapped fields on Alerts table #154714 using isMapped from fieldSpec
• [Security Solution] "Filter In", "Filter Out" and "Show top values" are not working for alerts table Data under cases.  #134442

Phase 2 (Use CellActions package inside Discover)

• Update Discover plugin to use CellActions [Security Solution] Use CellActions registry in Discover data grid #157201
• Add support for Number and Boolean types [CellActions] Add support for Number type #159298
• [WIP] Improve CellActions to support Discover use case [SecuritySolutions] Update CellActions to support all types used by Discover  #160524
  • Change the CellActions type to value: Serializable.
  • Whitelist the field.type in the isCompatible of every action.
  • Add the proper validations and value castings in the execute of every action.
  • Remove the whitelist from DiscoverGrid and pass the value directly to CellActions.

Existing architecture

There are a few concepts of the hover actions `security_solution` is operating with: cell actions of the TGrid, event details. The root of the functionality is located in the `timelines` plugin and exposed through the plugin public interface as `getHoverActions` hook. The diagram below shows the usage of the hook across plugins (security_solution, osquery, kubernetes_security, threat_inteligence):

1. HoverActions component and useHoverActions hook. Retrieving available actions from timelines.getHoverActions by usage of the hook useHoverActionsItems:

2. useHoverActions hook is used by DraggableWraper

3. `DraggableWraper` is used by `FormattedFieldValue` component, which belongs to `DefaultCellRenderer` and `defaultCellActions` hierarchies:

4. Another branch of usage of the HoverActions component is moved to ActionCell component:

5. A separate threat where timelines.getHoverActions is used directly by the component belongs to ExpandedCellValueActionsComponent. This tree of the components is ended by the hook useRenderCellValue (used for registering cell actions for the new alerts table in Cases) and DefaultCellRenderer (used by StatefulEventsViewer to path the available cell actions to the TGrid)

6. And final direct usage set of timelines.getHoverActions is allocated by defaultCellActions

Proposal diagram: https://whimsical.com/hoveractions-8t627KZTFtqK97rWDfgKxw

[elasticmachine]

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

[semd]

We could assess the possibility of doing something similar to what the Kibana Dashboards plugin does with its chart actions, they are pretty similar to our hover actions:

Kibana Dashboards actions

In summary, the pattern is based on a registry of actions defined inside the plugin (code). The action registry is stateful, it needs core and plugins dependencies in order to work, so they are defined in the plugin with all the action logic.

Then, the different components where the actions need to be displayed get those registered actions, they are rendered inside charts, legends, menus... Depending on the trigger that the action has been associated with (example).

What we could do

We could use a similar pattern in Security, starting by creating a new trigger (group of actions) for the "hoverActions", and registering all of them inside the security plugin (filter in, filter out, add to timeline, copy...). We will need the core and plugins dependencies and also the store to implement all those actions.

To render the hover actions we could create a new package. This component would need the getTriggerCompatibleActions function to be passed from the plugin in order to stay stateless, it will retrieve all the compatible hover actions from the registry and render them, it should be pretty small since all the complexity of the actions will be extracted from it.

Then we would be able to render this "hoverActions" packaged component in all the places inside (or outside) Security where we need to show hover actions, using a minimal set of props.

I am sure I am missing things on the way and there might be other issues to consider, but that is a pattern that is currently working on the Dashboards side, so probably it's worth doing a proper investigation, and maybe a POC.

@YulNaumenko @stephmilovic @machadoum @michaelolo24

[machadoum]

I like this approach, and I agree with implementing a POC. The first step could be extracting HoverActions component to a package and providing the list of actions as props or context.

It would be nice to define a clear set of requirements for the new architecture. Here are my 5 cents:

• Every plugin should be able to add custom Actions to the registry (AddToTimeline, AddToCase, etc...).
• Plugins should be able to render <HoverActions /> without the need to import other plugins or services.
• HoverActions component should allow customization of the displayed actions (<HoverActions actions={['copy']}/>)

Questions: Should HoverActions also accept custom actions as props? I foresee some specific table or field with actions that only make sense for that component.

[YulNaumenko]

I've reviewed the approach with uiActions, which Dashboards is using and it seems very reasonable to follow. But I still have a few concerns:

• there is still dependency from Dashboards to the other plugin uiActions: UiActionsStart;. In our case it seems like (for example)osquery plugin will require the link to the security_solution to register theirs actions. @semd maybe you've meant that security_solution could own all the actions registration and osquery will get theirs actions by using the HoverActions package with the proper trigger?
  What if at some day osquery (or some other plugin) will decide to add their own hover action, what should they do?

• Here is the example of the uiActions architecture principle:

According to that we should have a third party plugin (in their case it is uiActions) to own the registry/trigger logic for the actions and consumers. How do we suppose to manage this outside of security_solution without the dependency to it?

Another thing, which I have in mind is ability to use all available Actions which were designed by other teams.
Currently we have FilterIn, FilterOut in Discover table. So why not to have a single package for FilterIn and FilterOut and let Discover to use ours?

I'm not sure yet how the approach with each action as a package will work, but it looks more extendable and reusable across plugins.
But for internal security_solution HoverActions usage I think we can use the registry pattern Sergi mentioned to specify the variety of the different usage purposes - tables, timeline, flyouts, etc.

[maxcold]

Great initiative! I think threat_intelligence plugin will benefit from improvements made here. Btw small note about the naming - does it make sense to get rid of hover in the naming? It doesn't seem that actions appear on hover in TGrid initially should be that definitive of the name

[semd]

Once this migrations is finished we'll be able to do a fix for #154714

[semd]

The only missing task is this one, whose goal is solely standardizing a use case that is only used in a couple of places, and has already been solved using metadata.

Since everything has already been migrated to cell-action inside Security, and the last task is just an enhancement, I am de-scoping it from the epic so we can close it. We can do that separately if more use cases appear.

Kudos to @machadoum 👏

[machadoum]

This is awesome! Thank you all for the effort! 🥳 🍾