[Security] [Cases] Manage timeline UI API

[stephmilovic]

Summary

Introduces a new hook, useTimelineManager, to manage timelines at a global level. The hook is implemented by wrapping the entire app in a context provider <ManageGlobalTimeline>, and the useManageTimeline hook is then called within the app wherever we want to expose the useTimelineManager() methods . The following timeline data is now managed in this hook, indexed by timelineId:

interface ManageTimeline {
  documentType: string;
  filterManager?: FilterManager;
  footerText: string;
  id: string;
  indexToAdd: string[] | null;
  isLoading: boolean;
  loadingText: string;
  queryFields: string[];
  selectAll: boolean;
  timelineRowActions: TimelineRowAction[];
  title: string;
  unit: (totalCount: number) => string;
}

The hook returns the following methods:

interface UseTimelineManager {
  getManageTimelineById: (id: string) => ManageTimeline;
  getTimelineFilterManager: (id: string) => FilterManager | undefined;
  initializeTimeline: (newTimeline: ManageTimelineInit) => void;
  isManagedTimeline: (id: string) => boolean;
  setIsTimelineLoading: (isLoadingArgs: { id: string; isLoading: boolean }) => void;
  setTimelineRowActions: (actionsArgs: {
    id: string;
    queryFields?: string[];
    timelineRowActions: TimelineRowAction[];
  }) => void;
  setTimelineFilterManager: (filterArgs: { id: string; filterManager: FilterManager }) => void;
}

Timeline Row Actions

One of the new methods introduced in useTimelineManager is setTimelineRowActions. This hook sets the icon actions that render at the beginning of a row in timeline as highlighted in the below screenshot.

This is how the interface for timelineRowAction reads:

export interface TimelineRowActionOnClick {
  eventId: string;
  ecsData: Ecs;
}

export interface TimelineRowAction {
  ariaLabel?: string;
  dataTestSubj?: string;
  displayType: 'icon' | 'contextMenu';
  iconType: string;
  id: string;
  isActionDisabled?: boolean;
  onClick: ({ eventId, ecsData }: TimelineRowActionOnClick) => void;
  content: string;
  width?: number;
}

We can now display actions in either the existing top level icon pattern or a within a new context menu icon by setting displayType to either icon or contextMenu. width only needs to be set on displayType: icon. Here is the same action displayed first as an icon, and next as a contextMenu

NOTE TO TESTER

Add the following object to the array returned in getSignalsActions within x-pack/plugins/siem/public/alerts/components/signals/default_config.tsx in order to test the contextMenu:

  {
    onClick: ({ eventId }: TimelineRowActionOnClick) =>
      updateSignalStatusAction({
        signalIds: [eventId],
        status,
        setEventsLoading,
        setEventsDeleted,
      }),
    id: 'updateSignalStatus',
    iconType: status === FILTER_OPEN ? 'securitySignalDetected' : 'securitySignalResolved',
    isActionDisabled: !canUserCRUD || !hasIndexWrite,
    dataTestSubj: 'update-signal-status',
    ariaLabel: 'Update signal status',
    content: status === FILTER_OPEN ? i18n.ACTION_OPEN_SIGNAL : i18n.ACTION_CLOSE_SIGNAL,
    displayType: 'contextMenu',
  },

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)

[spong]

Checked out locally, and verified we've got all the features we need to support our 7.9 development effort! 🚀 🌕

Left a couple comments around the popover itself, but other than that LGTM from the Detections side. Nice implementation here @stephmilovic -- happy to have a nice easy way to fetch and manage timeline configurations! 🙂

PS: In testing, a future feature came to mind that I wanted to mention. It would be nice if we had the ability to programmatically generate/disable/hide actions for a given row based on the underlying row event data. This would be nice for hiding certain actions that aren't relevant to a specific event, or you know, all sorts of other things...😅 We almost ended up having this as a requirement as we had two separate actions Add Endpoint Exception and Add Rule Exception(which would require us to introspect the row event data to know which to show/hide), but they've since been combined to the Add Exception action, so we can key off of the event data within the action itself.

Just commenting as this would change the implementation a little, and may end up being something we'll have to support in the future. Will chat with product/design tomorrow to see how near in the future something like this might be. Either way, awesome improvements here -- thanks again @stephmilovic!

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: f88f038

History

• 💚 Build #51488 succeeded 0c87f68
• 💚 Build #50781 succeeded e0039d7
• 💔 Build #50619 failed d639aa2
• 💔 Build #50569 failed 9666d0c
• 💔 Build #50468 failed f9469c6

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[elasticmachine]

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