Skip to content
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

[Security Solution] [RAC] Local storage and the Reset Fields button are not working as expected for the Security > Alerts view #110524

Closed
andrew-goldstein opened this issue Aug 30, 2021 · 5 comments
Labels
bug Fixes for quality problems that affect the customer experience fixed impact:critical This issue should be addressed immediately due to a critical level of impact on the product. QA:Validated Issue has been validated by QA Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Threat Hunting Security Solution Threat Hunting Team v7.15.0

Comments

@andrew-goldstein
Copy link
Contributor

Describe the bug:

Local storage and the Reset Fields button are not working as expected for the Security > Alerts view. As a result:

  • The fields selected by a user in the Security > Alerts view are always (unexpectedly) reset to the defaults when a browser tab is closed and re-opened, because local storage is not working as-expected
  • The only way to reset the Security > Alerts view to the default set of columns is to close and re-open the browser tab, because Reset Fields is not working as-expected

Noted while desk testing the (unrelated) fix for #110043 in #110464

Kibana/Elasticsearch Stack version:

7.15 BC3

Steps to reproduce:

To Reproduce:

  1. Close all browser tabs connected to the Kibana instance you're using for testitng

  2. Use your browser's cache management to delete both cookies and local storage related to your Kibana instance (note: this may be localhost if you're running Kibana locally)

  3. Open a new browser tab and navigate to the root of your Kibana instance, e.g. http://localhost:5601, and ensure there is no URL query state in the address bar

  4. Navigate to the Security > Alerts page

Expected results:

  • Per the screenshot below, the following default columns are displayed
    • @timestamp
    • Rule
    • Severity
    • Risk Score
    • Reason
    • host.name
    • user.name
    • process.name
    • file.name
    • source.ip
    • destination.ip

default columns

Above: the default columns in the Security Solution Alerts table

  1. Open the browser's dev tools (Inspect the page in Chrome), and navigate to the dev tools tab that displays local storage (e.g. the Application tab in Chrome), as shown in the screenshot below:

localstorage-initial-state

Above: The initial state of local storage, as viewed in the Application tab of Chrome dev tools

  1. Click the Fields button in the Alerts table to display the Fields browser modal

Expected result

  • The Fields browser is displayed
  1. Click the cloud category in the Fields browser to select it

  2. Click the View all clouds fields button

Expected result:

  • All the fields in the cloud category are selected, as shown in the screenshot below:

all-cloud-fields-selected

Above: all fields in the cloud category are selected

  1. Click Close to close the Fields browser

Expected results:

  • The alerts table displays the @timestamp field, followed by all the cloud fields, as shown in the screenshot below:

cloud-fields-in-alerts-table

Above: all cloud fields in the alerts table

  1. Once again, examine the dev tools tab (Application in Chrome) that displays local storage, as shown in the screenshot below for the persisted state of the columns:

Expected results:

  • To ensure the state of perisisted columns is maintained after the browser tab is closed and re-opened, a local storage key named timelines has been created in local storage, as shown in the screenshot below (taken from an eariler version of Kibana, 7.12 in this example, because this functionality is not working as expected in the 7.14 release):

localstorage-expected

  • The Value of the timelines local storage key includes persistence for all of cloud fields added to the Security > Alerts table, as shown in the following JSON snippit (from a 7.12 instance):
{
   "detections-page":{
      "id":"detections-page",
      "activeTab":"query",
      "prevActiveTab":"query",
      "columns":[
         {
            "category":"base",
            "columnHeaderType":"not-filtered",
            "description":"Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events.",
            "example":"2016-05-23T08:05:34.853Z",
            "id":"@timestamp",
            "type":"date",
            "aggregatable":true,
            "width":190
         },
         {
            "category":"cloud",
            "columnHeaderType":"not-filtered",
            "description":"The cloud account or organization id used to identify different entities in a multi-tenant environment. Examples: AWS account id, Google Cloud ORG Id, or other unique identifier.",
            "example":"666777888999",
            "id":"cloud.account.id",
            "type":"string",
            "aggregatable":true,
            "width":180
         },
         {
            "category":"cloud",
            "columnHeaderType":"not-filtered",
            "description":"Availability zone in which this host is running.",
            "example":"us-east-1c",
            "id":"cloud.availability_zone",
            "type":"string",
            "aggregatable":true,
            "width":180
         },
         // ...
         }
      ],
      // ...
   }
}

Above: in 7.12, the value of the timelines key includes persistence of the cloud fields that were added to the Alerts table

Actual results:

  • The timelines key was NOT created in local storage
  • The cloud fields are NOT persisted as JSON for the alerts page (under the missing timelines local storage key)
  1. Close the browser tab displaying Kibana

  2. Once again, open a new browser tab and navigate to root Kibana, e.g. http://localhost:5601, ensuring there is no URL state in the address bar

  3. Once again, navigate to the Security > Alerts page

Expected result

  • The alerts table displays the @timestamp field and all the fields from the cloud category, because the fields were read from local storage (as seen in the 7.12 release used in this example)

Actual result

  • The alerts table does NOT display the cloud fields. Instead, it (incorrectly) displays the default columns as noted in step 4, because the persisted column configuration was not read from local storage
  1. Once again, click the Fields button

Expected result

  • The Fields browser is displayed
  1. Once again, click the cloud category

  2. Once again, click the View all cloud fields button

Expected result:

  • All the fields in the cloud category are selected
  1. Click Close to close the Fields browser

Expected results:

  • The alerts table displays the @timestamp field, followed by all the cloud fields
  1. Now, (one last time), click the Fields button in the Alerts table to display the Fields browser modal

Expected result

  • The Fields browser is displayed
  1. Click the Reset Fields button

Expected result

  • The Fields browser is closed

  • The following default columns are displayed

    • @timestamp
    • Rule
    • Severity
    • Risk Score
    • Reason
    • host.name
    • user.name
    • process.name
    • file.name
    • source.ip
    • destination.ip

    Actual results

  • The Fields browser is closed

  • Instead of restoring the expected default columns (including Reason), a different column set that includes message, event.category, event.action... is displayed, per the following screenshot:

non-default-fields

Above: The alerts table is reset to non-default fields (e.g. there's no Reason field)

Other observations / notes

  • After performing similar steps to the ones described above, the Host > Events view does create the expected timelines key in local storage

  • The Local storage of selected columns and Reset fields functionality should be verified in the following views:

    • Alerts table on the Detections page
    • Alerts table on the Rule Details page
    • Events and External alerts tables on the Host Details page
    • Events and External alerts tables on the Host Page
    • External alerts on the Network page
@andrew-goldstein andrew-goldstein added bug Fixes for quality problems that affect the customer experience triage_needed impact:critical This issue should be addressed immediately due to a critical level of impact on the product. Team:Threat Hunting Security Solution Threat Hunting Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. v7.15.0 labels Aug 30, 2021
@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

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

@MadameSheema
Copy link
Member

@karanbirsingh-qasource can you please validate the fix of this issue on 7.15BC5? Thanks :)

@MadameSheema
Copy link
Member

This issue looks fixed on 7.15 branch (dae544a).

Pending to close the ticket once the issue is validated by @karanbirsingh-qasource on 7.15BC5

@MadameSheema MadameSheema assigned ghost and unassigned semd Sep 8, 2021
@ghost
Copy link

ghost commented Sep 9, 2021

Hi @MadameSheema

we have validated this issue on 7.15.0 BC5 and found it Fixed . Timeline start getting under local storage dev section with the correct details of fields. reset button take back to default set of columns and all data of that default columns shows correctly.

Build Details:

Version: 7.15.0 BC5
Commit:0239ff6864dd9930cfe9bcd9a679272f2b7465c2
Build:43957

Please find below details observation for each of the steps .

Steps Actions Remark
Close all browser tabs connected to the Kibana instance you're using for testing Done
Use your browser's cache management to delete both cookies and local storage related to your Kibana instance Done • Cleared the Cache for Local Host• Cleared the Local Storage for LocalHost:5601
Open a new browser tab and navigate to the root of your Kibana instance, e.g. http://localhost:5601, and ensure there is no URL query state in the address bar Done
Navigate to the Security > Alerts page Expected default columns were displayed List of Column displayed on Kibana: •timestamp •Rule •Severity •Risk Score •Reason •host.name •user.name •process.name •file.name •source.ip •destination.ip
Open the browser's dev tools (Inspect the page in Chrome), and navigate to the dev tools tab that displays local storage (e.g. the Application tab in Chrome), as shown in the screenshot below: The initial state of local storage, as viewed in the Application tab of Chrome dev tools image
Click the Fields button in the Alerts table to display the Fields browser modal- Click on Cloud category - Click the View all clouds fields button • Field Modal Opened on browser• All the Cloud field got selected in field modal • The alerts table displays the @timestamp field, followed by all the cloud fields, • Total 12 columns shown on alert table [ 11 Cloud fields + 1 Timestamp field ]image • The timelines key was created in local storage image
Check Dev Tool Application Data Persisted state of the columns after the browser tab is closed and re-opened under timeline key under local storage • The cloud fields are persisted as JSON for the alerts pageimage• Complete json file for above timeline key : json-1.txt
Close the browser tab displaying Kibana Once again, open a new browser tab and navigate to root Kibana Go to Security > Alerts page The alerts table displays the @timestamp field and all the fields from the cloud category, image
Once again, click the Fields button Once again, click the cloud category Once again, click the View all cloud fields button Click Close to close the Fields browser • The Fields browser is displayed• All the fields in the cloud category are selected• The alerts table displays the @timestamp field, followed by all the cloud fields Pass ✔️
Now, (one last time), click the Fields button in the Alerts table to display the Fields browser modal Click the Reset Fields button •The Fields browser is displayed• The Fields browser is closed default columns got displayed• Cloud Field stops showing • Total 11 columns shown on alert table imageimage• Timeline Key information: image• Complete json file for above timeline key : json-2.txt
Validated that timeline key creation for the Host > Event Page Pass ✔️ image
Validated the Local storage of selected columns and Reset fields for Alerts table on the Detections page • Timeline key created , displays details of all the selected fields• Reset button , reset to default field • Columns fields stop showing Pass ✔️
Validated the Local storage of selected columns and Reset fields for Alerts table on the Rule Details page • Timeline key created , displays details of all the selected fields• Reset button , reset to default field • Columns fields stop showing Pass ✔️ image
Validated the Local storage of selected columns and Reset fields for Events and External alerts tables on the Host Details page • Timeline key created , displays details of all the selected fields• Reset button , reset to default field • Columns fields stop showing Pass ✔️ • External Alerts image • Event page image
Validated the Local storage of selected columns and Reset fields for Events and External alerts tables on the Host Page • Timeline key created , displays details of all the selected fields• Reset button , reset to default field • Columns fields stop showing Pass ✔️ • Event page image • External Alert pageimage
Validated the Local storage of selected columns and Reset fields for Alerts table on the External alerts on the Network page • Timeline key created , displays details of all the selected fields• Reset button , reset to default field • Columns fields stop showing Pass ✔️

Hence we are closing this issue.

thanks !!

c.c. thanks @andrew-goldstein for sharing the very detailed reproducibility steps .

@ghost ghost closed this as completed Sep 9, 2021
@ghost ghost added the QA:Validated Issue has been validated by QA label Sep 9, 2021
andrew-goldstein added a commit to andrew-goldstein/kibana that referenced this issue Oct 15, 2021
…lastic#113090>, as proposed [here](elastic#113090 (comment)):

- Configures the `Columns` popover to be consistent with `Discover`
- Changes the `Hide column` action to `Remove column`, to be consistent with `Discover`
- Persists updates to the `Columns` popover order in `local storage`
- Restores the feature to persist column widths in `local storage`

- We now pass `false` to the `allowHide` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid):

![allow_hide](https://user-images.githubusercontent.com/4459398/136114714-02f25b97-86af-47e5-9adc-1177d5a2c715.png)

This makes all `EuiDataGrid`-based views in the Security Solution consistent with `Discover`'s use of the  `EuiDataGrid` `Columns` popover.

In `7.15`, the `Columns` popover includes the _hide column_ toggle, as shown in the screenshot below:

![alerts_columns_popover_7_15](https://user-images.githubusercontent.com/4459398/136112441-455ddbeb-dea3-4837-81ad-32d6c82c11fe.png)

_Above: The `Columns` popover in the `7.15` `Alerts` table_

The `Columns` popover in `Discover`'s `EuiDataGrid`-based table does not display the hide column toggle, as shown the screenshot below:

![columns_popover_discover](https://user-images.githubusercontent.com/4459398/136112856-7e42c822-2260-4759-ac78-5bea63a171c7.png)

_Above: The `EuiDataGrid` `Columns` popover in `Discover`, in `master`_

Passing `false` to the `allowHide` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid) API makes the `Columns` popover in all `EuiDataGrid`-based views in the Security Solution consistent with `Discover`, as illustrated by the screenshot below:

![alerts_columns_popover_no_hide](https://user-images.githubusercontent.com/4459398/136112980-d4219fbd-1443-4612-8cdb-b97bee8b97ef.png)

_Above: The `Columns` popover is now consistent with `Discover`_

- The `Hide column` action shown in the `7.15` alerts table is changed to `Remove column`, making it consistent with `Discover`'s use of `EuiDataGrid`

In `7.15`, the `Alerts` table has a `Hide column` action, as shown in the screenshot below:

![hide_column](https://user-images.githubusercontent.com/4459398/136115681-9e0da144-a981-4352-8092-9368d74cd153.png)

_Above: The `Hide Column` action in the `7.15` `Alerts` table_

In `7.15`, clicking the `Hide Column` action shown in the screenshot above hides the column, but does not remove it.

In `7.15`, columns may only be removed by un-checking them in the `Fields` browser, or by un-toggling them in the Alerts / Events details popover. Both of those methods require multiple clicks, and require uses to re-find the field in the modal or popover before it may be toggled for removal.

In `Discover`, users don't hide columns.

In `Discover`, users directly remove columns by clicking the `Remove column` action, shown in the screenshot below:

![discover_remove_column](https://user-images.githubusercontent.com/4459398/136114295-f018a561-f9ee-4ce4-a9c6-0fcd7f71e67b.png)

_Above: The `Remove column` action in `Discover`'s use of `EuiDataGrid` in `master`_

All `EuiDataGrid`-based views in the Security Solution were made consistent with `Discover` by replacing the `Hide column` action with `Remove column`, per the screenshot below:

![remove_column_after](https://user-images.githubusercontent.com/4459398/137047582-3c4d6cb0-ac12-4c50-9c34-0c4ef5536550.png)

_Above: The `Remove column` action in the Alerts table_

Note: the `Remove column` action shown above appears as the last item in the popover because it's specified via the `EuiDataGrid` `EuiDataGridColumnActions` > `additonal` API, which appends additonal actions to the end of popover, after the built-in actions:

![additional](https://user-images.githubusercontent.com/4459398/137047825-625002b3-5cd6-4b3e-87da-e76dbaf2a827.png)

- Persist column order updates to `local storage` when users update the order of columns via the `Columns` popover

The following PR <elastic#110685> restored partial support for persisting columns across page refreshes via `local storage`, but the Redux store was not updated when users sort columns via the `Columns` popover, an shown in the animated gif below:

![ordering_via_columns](https://user-images.githubusercontent.com/4459398/136119497-65f76f49-091c-4a45-b8d3-1e5ef80ccbb2.gif)

_Above: Ordering via the `Columns` popover is not persisted to `local storage` in `7.15`_

This PR utilizes the `setVisibleColumns` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid) API as a callback to update Redux when the columns are sorted, which will in-turn update `local storage` to persist the new order across page refreshes:

![setVisibleColumns](https://user-images.githubusercontent.com/4459398/136117249-628bb147-a860-4ccf-811a-0e57a99296fb.png)

In previous releases, resized column widths were peristed in `local storage` to persist across page refreshes, as documented in <elastic#110524> :

```
{
   "detections-page":{
      "id":"detections-page",
      "activeTab":"query",
      "prevActiveTab":"query",
      "columns":[
         {
            "category":"base",
            "columnHeaderType":"not-filtered",
            "description":"Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events.",
            "example":"2016-05-23T08:05:34.853Z",
            "id":"@timestamp",
            "type":"date",
            "aggregatable":true,
            "width":190
         },
         {
            "category":"cloud",
            "columnHeaderType":"not-filtered",
            "description":"The cloud account or organization id used to identify different entities in a multi-tenant environment. Examples: AWS account id, Google Cloud ORG Id, or other unique identifier.",
            "example":"666777888999",
            "id":"cloud.account.id",
            "type":"string",
            "aggregatable":true,
            "width":180
         },
         {
            "category":"cloud",
            "columnHeaderType":"not-filtered",
            "description":"Availability zone in which this host is running.",
            "example":"us-east-1c",
            "id":"cloud.availability_zone",
            "type":"string",
            "aggregatable":true,
            "width":180
         },
         // ...
         }
      ],
      // ...
   }
}
```

_Above: column widths were persisted to `local storage` in previous release, (going at least back to `7.12`)_

In this PR, we utilize the `onColumnResize` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid) API as a callback to update Redux when the columns are sorted via the `Columns` popover. Updating Redux will in-turn update `local storage`, so resized columns widths will persist across page refreshes:

![onColumnResize](https://user-images.githubusercontent.com/4459398/136120062-3b0bebce-9c44-47fc-9956-48fe07a30f83.png)

The Alerts page `Trend` chart and table were updated to include the following additional `Stack by` fields (CC @paulewing):

```
process.name
file.name
hash.sha256
```

per the before / after screenshots below:

![alerts-trend-before](https://user-images.githubusercontent.com/4459398/137045011-7da4530b-0259-4fd4-b903-9eee6c26d02f.png)

_Above: The Alerts `Trend` Stack by fields in `7.15` (before)_

![alerts-trend-after](https://user-images.githubusercontent.com/4459398/137045023-d0ae987c-a474-4123-a05b-a6ad2fc52922.png)

_Above: The Alerts `Trend` `Stack by` fields (after the addition of the `process.name`, `file.name`, and `hash.sha256` fields)_

CC: @monina-n @paulewing
andrew-goldstein added a commit that referenced this issue Oct 16, 2021
…nd the Remove Column action (#114742)

## [Security Solution] Restores Alerts table local storage persistence and the Remove Column action

This PR implements the following changes summarized below to address <#113090>, as proposed [here](#113090 (comment)):

- Configures the `Columns` popover to be consistent with `Discover`
- Changes the `Hide column` action to `Remove column`, to be consistent with `Discover`
- Persists updates to the `Columns` popover order in `local storage`
- Restores the feature to persist column widths in `local storage`

### Configures the `Columns` popover to be consistent with `Discover`

- We now pass `false` to the `allowHide` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid):

![allow_hide](https://user-images.githubusercontent.com/4459398/136114714-02f25b97-86af-47e5-9adc-1177d5a2c715.png)

This makes all `EuiDataGrid`-based views in the Security Solution consistent with `Discover`'s use of the  `EuiDataGrid` `Columns` popover.

In `7.15`, the `Columns` popover includes the _hide column_ toggle, as shown in the screenshot below:

![alerts_columns_popover_7_15](https://user-images.githubusercontent.com/4459398/136112441-455ddbeb-dea3-4837-81ad-32d6c82c11fe.png)

_Above: The `Columns` popover in the `7.15` `Alerts` table_

The `Columns` popover in `Discover`'s `EuiDataGrid`-based table does not display the hide column toggle, as shown the screenshot below:

![columns_popover_discover](https://user-images.githubusercontent.com/4459398/136112856-7e42c822-2260-4759-ac78-5bea63a171c7.png)

_Above: The `EuiDataGrid` `Columns` popover in `Discover`, in `master`_

Passing `false` to the `allowHide` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid) API makes the `Columns` popover in all `EuiDataGrid`-based views in the Security Solution consistent with `Discover`, as illustrated by the screenshot below:

![alerts_columns_popover_no_hide](https://user-images.githubusercontent.com/4459398/136112980-d4219fbd-1443-4612-8cdb-b97bee8b97ef.png)

_Above: The `Columns` popover is now consistent with `Discover`_

## Changes the `Hide column` action to `Remove column`, to be consistent with `Discover`

- The `Hide column` action shown in the `7.15` alerts table is changed to `Remove column`, making it consistent with `Discover`'s use of `EuiDataGrid`

In `7.15`, the `Alerts` table has a `Hide column` action, as shown in the screenshot below:

![hide_column](https://user-images.githubusercontent.com/4459398/136115681-9e0da144-a981-4352-8092-9368d74cd153.png)

_Above: The `Hide Column` action in the `7.15` `Alerts` table_

In `7.15`, clicking the `Hide Column` action shown in the screenshot above hides the column, but does not remove it.

In `7.15`, columns may only be removed by un-checking them in the `Fields` browser, or by un-toggling them in the Alerts / Events details popover. Both of those methods require multiple clicks, and require uses to re-find the field in the modal or popover before it may be toggled for removal.

In `Discover`, users don't hide columns.

In `Discover`, users directly remove columns by clicking the `Remove column` action, shown in the screenshot below:

![discover_remove_column](https://user-images.githubusercontent.com/4459398/136114295-f018a561-f9ee-4ce4-a9c6-0fcd7f71e67b.png)

_Above: The `Remove column` action in `Discover`'s use of `EuiDataGrid` in `master`_

All `EuiDataGrid`-based views in the Security Solution were made consistent with `Discover` by replacing the `Hide column` action with `Remove column`, per the screenshot below:

![remove_column_after](https://user-images.githubusercontent.com/4459398/137047582-3c4d6cb0-ac12-4c50-9c34-0c4ef5536550.png)

_Above: The `Remove column` action in the Alerts table_

Note: the `Remove column` action shown above appears as the last item in the popover because it's specified via the `EuiDataGrid` `EuiDataGridColumnActions` > `additonal` API, which appends additonal actions to the end of popover, after the built-in actions:

![additional](https://user-images.githubusercontent.com/4459398/137047825-625002b3-5cd6-4b3e-87da-e76dbaf2a827.png)

## Persists updates to the `Columns` popover order in `local storage`

- Persist column order updates to `local storage` when users update the order of columns via the `Columns` popover

The following PR <#110685> restored partial support for persisting columns across page refreshes via `local storage`, but the Redux store was not updated when users sort columns via the `Columns` popover, an shown in the animated gif below:

![ordering_via_columns](https://user-images.githubusercontent.com/4459398/136119497-65f76f49-091c-4a45-b8d3-1e5ef80ccbb2.gif)

_Above: Ordering via the `Columns` popover is not persisted to `local storage` in `7.15`_

This PR utilizes the `setVisibleColumns` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid) API as a callback to update Redux when the columns are sorted, which will in-turn update `local storage` to persist the new order across page refreshes:

![setVisibleColumns](https://user-images.githubusercontent.com/4459398/136117249-628bb147-a860-4ccf-811a-0e57a99296fb.png)

## Restores the feature to persist column widths in `local storage`

In previous releases, resized column widths were peristed in `local storage` to persist across page refreshes, as documented in <#110524> :

```
{
   "detections-page":{
      "id":"detections-page",
      "activeTab":"query",
      "prevActiveTab":"query",
      "columns":[
         {
            "category":"base",
            "columnHeaderType":"not-filtered",
            "description":"Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events.",
            "example":"2016-05-23T08:05:34.853Z",
            "id":"@timestamp",
            "type":"date",
            "aggregatable":true,
            "width":190
         },
         {
            "category":"cloud",
            "columnHeaderType":"not-filtered",
            "description":"The cloud account or organization id used to identify different entities in a multi-tenant environment. Examples: AWS account id, Google Cloud ORG Id, or other unique identifier.",
            "example":"666777888999",
            "id":"cloud.account.id",
            "type":"string",
            "aggregatable":true,
            "width":180
         },
         {
            "category":"cloud",
            "columnHeaderType":"not-filtered",
            "description":"Availability zone in which this host is running.",
            "example":"us-east-1c",
            "id":"cloud.availability_zone",
            "type":"string",
            "aggregatable":true,
            "width":180
         },
         // ...
         }
      ],
      // ...
   }
}
```

_Above: column widths were persisted to `local storage` in previous release, (going at least back to `7.12`)_

In this PR, we utilize the `onColumnResize` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid) API as a callback to update Redux when the columns are sorted via the `Columns` popover. Updating Redux will in-turn update `local storage`, so resized columns widths will persist across page refreshes:

![onColumnResize](https://user-images.githubusercontent.com/4459398/136120062-3b0bebce-9c44-47fc-9956-48fe07a30f83.png)

### Other changes

The Alerts page `Trend` chart and table were updated to include the following additional `Stack by` fields (CC @paulewing):

```
process.name
file.name
hash.sha256
```

per the before / after screenshots below:

![alerts-trend-before](https://user-images.githubusercontent.com/4459398/137045011-7da4530b-0259-4fd4-b903-9eee6c26d02f.png)

_Above: The Alerts `Trend` Stack by fields in `7.15` (before)_

![alerts-trend-after](https://user-images.githubusercontent.com/4459398/137045023-d0ae987c-a474-4123-a05b-a6ad2fc52922.png)

_Above: The Alerts `Trend` `Stack by` fields (after the addition of the `process.name`, `file.name`, and `hash.sha256` fields)_

CC: @monina-n @paulewing
kibanamachine pushed a commit to kibanamachine/kibana that referenced this issue Oct 16, 2021
…nd the Remove Column action (elastic#114742)

## [Security Solution] Restores Alerts table local storage persistence and the Remove Column action

This PR implements the following changes summarized below to address <elastic#113090>, as proposed [here](elastic#113090 (comment)):

- Configures the `Columns` popover to be consistent with `Discover`
- Changes the `Hide column` action to `Remove column`, to be consistent with `Discover`
- Persists updates to the `Columns` popover order in `local storage`
- Restores the feature to persist column widths in `local storage`

### Configures the `Columns` popover to be consistent with `Discover`

- We now pass `false` to the `allowHide` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid):

![allow_hide](https://user-images.githubusercontent.com/4459398/136114714-02f25b97-86af-47e5-9adc-1177d5a2c715.png)

This makes all `EuiDataGrid`-based views in the Security Solution consistent with `Discover`'s use of the  `EuiDataGrid` `Columns` popover.

In `7.15`, the `Columns` popover includes the _hide column_ toggle, as shown in the screenshot below:

![alerts_columns_popover_7_15](https://user-images.githubusercontent.com/4459398/136112441-455ddbeb-dea3-4837-81ad-32d6c82c11fe.png)

_Above: The `Columns` popover in the `7.15` `Alerts` table_

The `Columns` popover in `Discover`'s `EuiDataGrid`-based table does not display the hide column toggle, as shown the screenshot below:

![columns_popover_discover](https://user-images.githubusercontent.com/4459398/136112856-7e42c822-2260-4759-ac78-5bea63a171c7.png)

_Above: The `EuiDataGrid` `Columns` popover in `Discover`, in `master`_

Passing `false` to the `allowHide` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid) API makes the `Columns` popover in all `EuiDataGrid`-based views in the Security Solution consistent with `Discover`, as illustrated by the screenshot below:

![alerts_columns_popover_no_hide](https://user-images.githubusercontent.com/4459398/136112980-d4219fbd-1443-4612-8cdb-b97bee8b97ef.png)

_Above: The `Columns` popover is now consistent with `Discover`_

## Changes the `Hide column` action to `Remove column`, to be consistent with `Discover`

- The `Hide column` action shown in the `7.15` alerts table is changed to `Remove column`, making it consistent with `Discover`'s use of `EuiDataGrid`

In `7.15`, the `Alerts` table has a `Hide column` action, as shown in the screenshot below:

![hide_column](https://user-images.githubusercontent.com/4459398/136115681-9e0da144-a981-4352-8092-9368d74cd153.png)

_Above: The `Hide Column` action in the `7.15` `Alerts` table_

In `7.15`, clicking the `Hide Column` action shown in the screenshot above hides the column, but does not remove it.

In `7.15`, columns may only be removed by un-checking them in the `Fields` browser, or by un-toggling them in the Alerts / Events details popover. Both of those methods require multiple clicks, and require uses to re-find the field in the modal or popover before it may be toggled for removal.

In `Discover`, users don't hide columns.

In `Discover`, users directly remove columns by clicking the `Remove column` action, shown in the screenshot below:

![discover_remove_column](https://user-images.githubusercontent.com/4459398/136114295-f018a561-f9ee-4ce4-a9c6-0fcd7f71e67b.png)

_Above: The `Remove column` action in `Discover`'s use of `EuiDataGrid` in `master`_

All `EuiDataGrid`-based views in the Security Solution were made consistent with `Discover` by replacing the `Hide column` action with `Remove column`, per the screenshot below:

![remove_column_after](https://user-images.githubusercontent.com/4459398/137047582-3c4d6cb0-ac12-4c50-9c34-0c4ef5536550.png)

_Above: The `Remove column` action in the Alerts table_

Note: the `Remove column` action shown above appears as the last item in the popover because it's specified via the `EuiDataGrid` `EuiDataGridColumnActions` > `additonal` API, which appends additonal actions to the end of popover, after the built-in actions:

![additional](https://user-images.githubusercontent.com/4459398/137047825-625002b3-5cd6-4b3e-87da-e76dbaf2a827.png)

## Persists updates to the `Columns` popover order in `local storage`

- Persist column order updates to `local storage` when users update the order of columns via the `Columns` popover

The following PR <elastic#110685> restored partial support for persisting columns across page refreshes via `local storage`, but the Redux store was not updated when users sort columns via the `Columns` popover, an shown in the animated gif below:

![ordering_via_columns](https://user-images.githubusercontent.com/4459398/136119497-65f76f49-091c-4a45-b8d3-1e5ef80ccbb2.gif)

_Above: Ordering via the `Columns` popover is not persisted to `local storage` in `7.15`_

This PR utilizes the `setVisibleColumns` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid) API as a callback to update Redux when the columns are sorted, which will in-turn update `local storage` to persist the new order across page refreshes:

![setVisibleColumns](https://user-images.githubusercontent.com/4459398/136117249-628bb147-a860-4ccf-811a-0e57a99296fb.png)

## Restores the feature to persist column widths in `local storage`

In previous releases, resized column widths were peristed in `local storage` to persist across page refreshes, as documented in <elastic#110524> :

```
{
   "detections-page":{
      "id":"detections-page",
      "activeTab":"query",
      "prevActiveTab":"query",
      "columns":[
         {
            "category":"base",
            "columnHeaderType":"not-filtered",
            "description":"Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events.",
            "example":"2016-05-23T08:05:34.853Z",
            "id":"@timestamp",
            "type":"date",
            "aggregatable":true,
            "width":190
         },
         {
            "category":"cloud",
            "columnHeaderType":"not-filtered",
            "description":"The cloud account or organization id used to identify different entities in a multi-tenant environment. Examples: AWS account id, Google Cloud ORG Id, or other unique identifier.",
            "example":"666777888999",
            "id":"cloud.account.id",
            "type":"string",
            "aggregatable":true,
            "width":180
         },
         {
            "category":"cloud",
            "columnHeaderType":"not-filtered",
            "description":"Availability zone in which this host is running.",
            "example":"us-east-1c",
            "id":"cloud.availability_zone",
            "type":"string",
            "aggregatable":true,
            "width":180
         },
         // ...
         }
      ],
      // ...
   }
}
```

_Above: column widths were persisted to `local storage` in previous release, (going at least back to `7.12`)_

In this PR, we utilize the `onColumnResize` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid) API as a callback to update Redux when the columns are sorted via the `Columns` popover. Updating Redux will in-turn update `local storage`, so resized columns widths will persist across page refreshes:

![onColumnResize](https://user-images.githubusercontent.com/4459398/136120062-3b0bebce-9c44-47fc-9956-48fe07a30f83.png)

### Other changes

The Alerts page `Trend` chart and table were updated to include the following additional `Stack by` fields (CC @paulewing):

```
process.name
file.name
hash.sha256
```

per the before / after screenshots below:

![alerts-trend-before](https://user-images.githubusercontent.com/4459398/137045011-7da4530b-0259-4fd4-b903-9eee6c26d02f.png)

_Above: The Alerts `Trend` Stack by fields in `7.15` (before)_

![alerts-trend-after](https://user-images.githubusercontent.com/4459398/137045023-d0ae987c-a474-4123-a05b-a6ad2fc52922.png)

_Above: The Alerts `Trend` `Stack by` fields (after the addition of the `process.name`, `file.name`, and `hash.sha256` fields)_

CC: @monina-n @paulewing
kibanamachine added a commit that referenced this issue Oct 16, 2021
…nd the Remove Column action (#114742) (#115301)

## [Security Solution] Restores Alerts table local storage persistence and the Remove Column action

This PR implements the following changes summarized below to address <#113090>, as proposed [here](#113090 (comment)):

- Configures the `Columns` popover to be consistent with `Discover`
- Changes the `Hide column` action to `Remove column`, to be consistent with `Discover`
- Persists updates to the `Columns` popover order in `local storage`
- Restores the feature to persist column widths in `local storage`

### Configures the `Columns` popover to be consistent with `Discover`

- We now pass `false` to the `allowHide` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid):

![allow_hide](https://user-images.githubusercontent.com/4459398/136114714-02f25b97-86af-47e5-9adc-1177d5a2c715.png)

This makes all `EuiDataGrid`-based views in the Security Solution consistent with `Discover`'s use of the  `EuiDataGrid` `Columns` popover.

In `7.15`, the `Columns` popover includes the _hide column_ toggle, as shown in the screenshot below:

![alerts_columns_popover_7_15](https://user-images.githubusercontent.com/4459398/136112441-455ddbeb-dea3-4837-81ad-32d6c82c11fe.png)

_Above: The `Columns` popover in the `7.15` `Alerts` table_

The `Columns` popover in `Discover`'s `EuiDataGrid`-based table does not display the hide column toggle, as shown the screenshot below:

![columns_popover_discover](https://user-images.githubusercontent.com/4459398/136112856-7e42c822-2260-4759-ac78-5bea63a171c7.png)

_Above: The `EuiDataGrid` `Columns` popover in `Discover`, in `master`_

Passing `false` to the `allowHide` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid) API makes the `Columns` popover in all `EuiDataGrid`-based views in the Security Solution consistent with `Discover`, as illustrated by the screenshot below:

![alerts_columns_popover_no_hide](https://user-images.githubusercontent.com/4459398/136112980-d4219fbd-1443-4612-8cdb-b97bee8b97ef.png)

_Above: The `Columns` popover is now consistent with `Discover`_

## Changes the `Hide column` action to `Remove column`, to be consistent with `Discover`

- The `Hide column` action shown in the `7.15` alerts table is changed to `Remove column`, making it consistent with `Discover`'s use of `EuiDataGrid`

In `7.15`, the `Alerts` table has a `Hide column` action, as shown in the screenshot below:

![hide_column](https://user-images.githubusercontent.com/4459398/136115681-9e0da144-a981-4352-8092-9368d74cd153.png)

_Above: The `Hide Column` action in the `7.15` `Alerts` table_

In `7.15`, clicking the `Hide Column` action shown in the screenshot above hides the column, but does not remove it.

In `7.15`, columns may only be removed by un-checking them in the `Fields` browser, or by un-toggling them in the Alerts / Events details popover. Both of those methods require multiple clicks, and require uses to re-find the field in the modal or popover before it may be toggled for removal.

In `Discover`, users don't hide columns.

In `Discover`, users directly remove columns by clicking the `Remove column` action, shown in the screenshot below:

![discover_remove_column](https://user-images.githubusercontent.com/4459398/136114295-f018a561-f9ee-4ce4-a9c6-0fcd7f71e67b.png)

_Above: The `Remove column` action in `Discover`'s use of `EuiDataGrid` in `master`_

All `EuiDataGrid`-based views in the Security Solution were made consistent with `Discover` by replacing the `Hide column` action with `Remove column`, per the screenshot below:

![remove_column_after](https://user-images.githubusercontent.com/4459398/137047582-3c4d6cb0-ac12-4c50-9c34-0c4ef5536550.png)

_Above: The `Remove column` action in the Alerts table_

Note: the `Remove column` action shown above appears as the last item in the popover because it's specified via the `EuiDataGrid` `EuiDataGridColumnActions` > `additonal` API, which appends additonal actions to the end of popover, after the built-in actions:

![additional](https://user-images.githubusercontent.com/4459398/137047825-625002b3-5cd6-4b3e-87da-e76dbaf2a827.png)

## Persists updates to the `Columns` popover order in `local storage`

- Persist column order updates to `local storage` when users update the order of columns via the `Columns` popover

The following PR <#110685> restored partial support for persisting columns across page refreshes via `local storage`, but the Redux store was not updated when users sort columns via the `Columns` popover, an shown in the animated gif below:

![ordering_via_columns](https://user-images.githubusercontent.com/4459398/136119497-65f76f49-091c-4a45-b8d3-1e5ef80ccbb2.gif)

_Above: Ordering via the `Columns` popover is not persisted to `local storage` in `7.15`_

This PR utilizes the `setVisibleColumns` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid) API as a callback to update Redux when the columns are sorted, which will in-turn update `local storage` to persist the new order across page refreshes:

![setVisibleColumns](https://user-images.githubusercontent.com/4459398/136117249-628bb147-a860-4ccf-811a-0e57a99296fb.png)

## Restores the feature to persist column widths in `local storage`

In previous releases, resized column widths were peristed in `local storage` to persist across page refreshes, as documented in <#110524> :

```
{
   "detections-page":{
      "id":"detections-page",
      "activeTab":"query",
      "prevActiveTab":"query",
      "columns":[
         {
            "category":"base",
            "columnHeaderType":"not-filtered",
            "description":"Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events.",
            "example":"2016-05-23T08:05:34.853Z",
            "id":"@timestamp",
            "type":"date",
            "aggregatable":true,
            "width":190
         },
         {
            "category":"cloud",
            "columnHeaderType":"not-filtered",
            "description":"The cloud account or organization id used to identify different entities in a multi-tenant environment. Examples: AWS account id, Google Cloud ORG Id, or other unique identifier.",
            "example":"666777888999",
            "id":"cloud.account.id",
            "type":"string",
            "aggregatable":true,
            "width":180
         },
         {
            "category":"cloud",
            "columnHeaderType":"not-filtered",
            "description":"Availability zone in which this host is running.",
            "example":"us-east-1c",
            "id":"cloud.availability_zone",
            "type":"string",
            "aggregatable":true,
            "width":180
         },
         // ...
         }
      ],
      // ...
   }
}
```

_Above: column widths were persisted to `local storage` in previous release, (going at least back to `7.12`)_

In this PR, we utilize the `onColumnResize` [EuiDataGrid API](https://elastic.github.io/eui/#/tabular-content/data-grid) API as a callback to update Redux when the columns are sorted via the `Columns` popover. Updating Redux will in-turn update `local storage`, so resized columns widths will persist across page refreshes:

![onColumnResize](https://user-images.githubusercontent.com/4459398/136120062-3b0bebce-9c44-47fc-9956-48fe07a30f83.png)

### Other changes

The Alerts page `Trend` chart and table were updated to include the following additional `Stack by` fields (CC @paulewing):

```
process.name
file.name
hash.sha256
```

per the before / after screenshots below:

![alerts-trend-before](https://user-images.githubusercontent.com/4459398/137045011-7da4530b-0259-4fd4-b903-9eee6c26d02f.png)

_Above: The Alerts `Trend` Stack by fields in `7.15` (before)_

![alerts-trend-after](https://user-images.githubusercontent.com/4459398/137045023-d0ae987c-a474-4123-a05b-a6ad2fc52922.png)

_Above: The Alerts `Trend` `Stack by` fields (after the addition of the `process.name`, `file.name`, and `hash.sha256` fields)_

CC: @monina-n @paulewing

Co-authored-by: Andrew Goldstein <[email protected]>
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience fixed impact:critical This issue should be addressed immediately due to a critical level of impact on the product. QA:Validated Issue has been validated by QA Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Threat Hunting Security Solution Threat Hunting Team v7.15.0
Projects
None yet
Development

No branches or pull requests

4 participants