From cd74ecfc2ee0367faacbc1a107d379bf2686dd8b Mon Sep 17 00:00:00 2001 From: Juan Pablo Djeredjian Date: Thu, 19 Dec 2024 12:29:27 -0300 Subject: [PATCH 1/5] [Security Solution] Test Plan for Rule Updates workflow (#203331) Partially resolves: https://github.com/elastic/kibana/issues/202078 ## Summary This PR refactors the test plans involving the Installation and Upgrade Workflows: - breaks down the gigantic `installation_and_upgrade.md` file into three files: - `installation.md` covering exclusively prebuilt rule install workflows - `upgrade.md` covering exclusively prebuilt rule upgrade workflows - `package_installation_and_upgrade.md` which covers scenarios for the installation and upgrades of the Prebuilt Rules package itself. The *Upgrade of Prebuilt Rules* (`upgrade.md`) was modified as follows: - expanded to cover scenarios detailed in the linked ticket (`Upgrading prebuilt rules one-by-one without preview` and `Upgrading prebuilt rules in bulk` in the Rule Updates table, including cases with and without conflicts, as well as a mixture of both) - internally refactored so that sections that will become legacy with the release of Milestone 3 were pushed to the end and marked as pending deletion once the feature is live. - from point above, the test plan now is in a better position to add the scenarios for the Three-Way-Diff upgrade workflow. cc @maximpn @nikitaindik ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: Maxim Palenov --- .../prebuilt_rules/installation.md | 559 ++++++++++++ .../package_installation_and_upgrade.md | 165 ++++ ...installation_and_upgrade.md => upgrade.md} | 809 ++++++------------ 3 files changed, 1005 insertions(+), 528 deletions(-) create mode 100644 x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation.md create mode 100644 x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/package_installation_and_upgrade.md rename x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/{installation_and_upgrade.md => upgrade.md} (55%) diff --git a/x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation.md b/x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation.md new file mode 100644 index 0000000000000..6f91d4958650c --- /dev/null +++ b/x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation.md @@ -0,0 +1,559 @@ +# Installation of Prebuilt Rules + +This is a test plan for the workflows of installing prebuilt rules. + +Status: `in progress`. The current test plan matches [Rule Immutability/Customization Milestone 3 epic](https://github.com/elastic/kibana/issues/174168). + +## Table of Contents + +- [Useful information](#useful-information) + - [Tickets](#tickets) + - [Terminology](#terminology) + - [Assumptions](#assumptions) + - [Non-functional requirements](#non-functional-requirements) + - [Functional requirements](#functional-requirements) +- [Scenarios](#scenarios) + - [Rule installation notifications on the Rule Management page](#rule-installation-and-upgrade-notifications-on-the-rule-management-page) + - [**Scenario: User is NOT notified when no prebuilt rules are installed and there are no prebuilt rules assets**](#scenario-user-is-not-notified-when-no-prebuilt-rules-are-installed-and-there-are-no-prebuilt-rules-assets) + - [**Scenario: User is NOT notified when all prebuilt rules are installed and up to date**](#scenario-user-is-not-notified-when-all-prebuilt-rules-are-installed-and-up-to-date) + - [**Scenario: User is notified when no prebuilt rules are installed and there are rules available to install**](#scenario-user-is-notified-when-no-prebuilt-rules-are-installed-and-there-are-rules-available-to-install) + - [**Scenario: User is notified when some prebuilt rules can be installed**](#scenario-user-is-notified-when-some-prebuilt-rules-can-be-installed) + - [**Scenario: User is notified when both rules to install and upgrade are available**](#scenario-user-is-notified-when-both-rules-to-install-and-upgrade-are-available) + - [**Scenario: User is notified after a prebuilt rule gets deleted**](#scenario-user-is-notified-after-a-prebuilt-rule-gets-deleted) + - [Rule installation workflow: base cases](#rule-installation-workflow-base-cases) + - [**Scenario: User can install prebuilt rules one by one**](#scenario-user-can-install-prebuilt-rules-one-by-one) + - [**Scenario: User can install multiple prebuilt rules selected on the page**](#scenario-user-can-install-multiple-prebuilt-rules-selected-on-the-page) + - [**Scenario: User can install all available prebuilt rules at once**](#scenario-user-can-install-all-available-prebuilt-rules-at-once) + - [**Scenario: Empty screen is shown when all prebuilt rules are installed**](#scenario-empty-screen-is-shown-when-all-prebuilt-rules-are-installed) + - [**Scenario: User can preview rules available for installation**](#scenario-user-can-preview-rules-available-for-installation) + - [**Scenario: User can install a rule using the rule preview**](#scenario-user-can-install-a-rule-using-the-rule-preview) + - [**Scenario: User can see correct rule information in preview before installing**](#scenario-user-can-see-correct-rule-information-in-preview-before-installing) + - [**Scenario: Tabs and sections without content should be hidden in preview before installing**](#scenario-tabs-and-sections-without-content-should-be-hidden-in-preview-before-installing) + - [Rule installation workflow: filtering, sorting, pagination](#rule-installation-workflow-filtering-sorting-pagination) + - [Rule installation workflow: misc cases](#rule-installation-workflow-misc-cases) + - [**Scenario: User opening the Add Rules page sees a loading skeleton until the package installation is completed**](#scenario-user-opening-the-add-rules-page-sees-a-loading-skeleton-until-the-package-installation-is-completed) + - [**Scenario: User can navigate from the Add Rules page to the Rule Management page via breadcrumbs**](#scenario-user-can-navigate-from-the-add-rules-page-to-the-rule-management-page-via-breadcrumbs) + - [Rule installation and upgrade via the Prebuilt rules API](#rule-installation-and-upgrade-via-the-prebuilt-rules-api) + - [**Scenario: API can install all prebuilt rules**](#scenario-api-can-install-all-prebuilt-rules) + - [**Scenario: API can install prebuilt rules that are not yet installed**](#scenario-api-can-install-prebuilt-rules-that-are-not-yet-installed) + - [**Scenario: API does not install prebuilt rules if they are up to date**](#scenario-api-does-not-installupgrade-prebuilt-rules-if-they-are-up-to-date) + - [Error handling](#error-handling) + - [**Scenario: Error is handled when any operation on prebuilt rules fails**](#scenario-error-is-handled-when-any-operation-on-prebuilt-rules-fails) + - [Authorization / RBAC](#authorization--rbac) + - [**Scenario: User with read privileges on Security Solution cannot install prebuilt rules**](#scenario-user-with-read-privileges-on-security-solution-cannot-install-prebuilt-rules) + +## Useful information + +### Tickets + +- [Rule Immutability/Customization epic](https://github.com/elastic/security-team/issues/1974)(internal) + +**Milestone 3 - Prebuilt Rules Customization:** +- [Milestone 3 epic ticket](https://github.com/elastic/kibana/issues/174168) +- [Tests for prebuilt rule upgrade workflow #202078](https://github.com/elastic/kibana/issues/202078) + +**Milestone 2:** +- [Ensure full test coverage for existing workflows of installing and upgrading prebuilt rules](https://github.com/elastic/kibana/issues/148176) +- [Write test plan and add test coverage for the new workflows of installing and upgrading prebuilt rules](https://github.com/elastic/kibana/issues/148192) + +### Terminology + +- **EPR**: [Elastic Package Registry](https://github.com/elastic/package-registry), service that hosts our **Package**. + +- **Package**: `security_detection_engine` Fleet package that we use to distribute prebuilt detection rules in the form of `security-rule` assets (saved objects). + +- **Real package**: actual latest stable package distributed and pulled from EPR via Fleet. + +- **Mock rules**: `security-rule` assets that are indexed into the `.kibana_security_solution` index directly in the test setup, either by using the ES client _in integration tests_ or by an API request _in Cypress tests_. + +- **Air-gapped environment**: an environment where Kibana doesn't have access to the internet. In general, EPR is not available in such environments, except the cases when the user runs a custom EPR inside the environment. + +- **CTA**: "call to action", usually a button, a link, or a callout message with a button, etc, that invites the user to do some action. + - CTA to install prebuilt rules - at this moment, it's a link button with a counter (implemented) and a callout with a link button (not yet implemented) on the Rule Management page. + - CTA to upgrade prebuilt rules - at this moment, it's a tab with a counter (implemented) and a callout with a link button (not yet implemented) on the Rule Management page. + +### Assumptions + +- Below scenarios only apply to prebuilt detection rules. +- Users should be able to install prebuilt rules on the `Basic` license and higher. +- EPR is available for fetching the package unless explicitly indicated otherwise. +- Only the latest **stable** package is checked for installation/upgrade and pre-release packages are ignored. + +### Non-functional requirements + +- Notifications, rule installation workflows should work: + - regardless of the package type: with historical rule versions or without; + - regardless of the package registry availability: i.e., they should also work in air-gapped environments. +- Rule installation and upgrade workflows should work with packages containing up to 15000 historical rule versions. This is the max number of versions of all rules in the package. This limit is enforced by Fleet. +- Kibana should not crash with Out Of Memory exception during package installation. +- For test purposes, it should be possible to use detection rules package versions lower than the latest. + +### Functional requirements + +- User should be able to install prebuilt rules with and without previewing what exactly they would install (rule properties). +- If user chooses to preview a prebuilt rule to be installed/upgraded, we currently show this preview in a flyout. +- In the prebuilt rule preview a tab that doesn't have any sections should not be displayed and a section that doesn't have any properties also should not be displayed. + +Examples of rule properties we show in the prebuilt rule preview flyout: + +```Gherkin +Examples: +| rule_type | property | tab | section | +│ All rule types │ Author │ Overview │ About │ +│ All rule types │ Building block │ Overview │ About │ +│ All rule types │ Severity │ Overview │ About │ +│ All rule types │ Severity override │ Overview │ About │ +│ All rule types │ Risk score │ Overview │ About │ +│ All rule types │ Risk score override │ Overview │ About │ +│ All rule types │ Reference URLs │ Overview │ About │ +│ All rule types │ False positive examples │ Overview │ About │ +│ All rule types │ Custom highlighted fields │ Overview │ About │ +│ All rule types │ License │ Overview │ About │ +│ All rule types │ Rule name override │ Overview │ About │ +│ All rule types │ MITRE ATT&CK™ │ Overview │ About │ +│ All rule types │ Timestamp override │ Overview │ About │ +│ All rule types │ Tags │ Overview │ About │ +│ All rule types │ Type │ Overview │ Definition │ +│ All rule types │ Related integrations │ Overview │ Definition │ +│ All rule types │ Required fields │ Overview │ Definition │ +│ All rule types │ Timeline template │ Overview │ Definition │ +│ All rule types │ Runs every │ Overview │ Schedule │ +│ All rule types │ Additional look-back time │ Overview │ Schedule │ +│ All rule types │ Setup guide │ Overview │ Setup guide │ +│ All rule types │ Investigation guide │ Investigation guide │ Investigation guide │ +│ Custom Query │ Index patterns │ Overview │ Definition │ +│ Custom Query │ Data view ID │ Overview │ Definition │ +│ Custom Query │ Data view index pattern │ Overview │ Definition │ +│ Custom Query │ Custom query │ Overview │ Definition │ +│ Custom Query │ Filters │ Overview │ Definition │ +│ Custom Query │ Saved query name │ Overview │ Definition │ +│ Custom Query │ Saved query filters │ Overview │ Definition │ +│ Custom Query │ Saved query │ Overview │ Definition │ +│ Custom Query │ Suppress alerts by │ Overview │ Definition │ +│ Custom Query │ Suppress alerts for │ Overview │ Definition │ +│ Custom Query │ If a suppression field is missing │ Overview │ Definition │ +│ Machine Learning │ Anomaly score threshold │ Overview │ Definition │ +│ Machine Learning │ Machine Learning job │ Overview │ Definition │ +│ Threshold │ Threshold │ Overview │ Definition │ +│ Threshold │ Index patterns │ Overview │ Definition │ +│ Threshold │ Data view ID │ Overview │ Definition │ +│ Threshold │ Data view index pattern │ Overview │ Definition │ +│ Threshold │ Custom query │ Overview │ Definition │ +│ Threshold │ Filters │ Overview │ Definition │ +│ Event Correlation │ EQL query │ Overview │ Definition │ +│ Event Correlation │ Filters │ Overview │ Definition │ +│ Event Correlation │ Index patterns │ Overview │ Definition │ +│ Event Correlation │ Data view ID │ Overview │ Definition │ +│ Event Correlation │ Data view index pattern │ Overview │ Definition │ +│ Indicator Match │ Indicator index patterns │ Overview │ Definition │ +│ Indicator Match │ Indicator mapping │ Overview │ Definition │ +│ Indicator Match │ Indicator filters │ Overview │ Definition │ +│ Indicator Match │ Indicator index query │ Overview │ Definition │ +│ Indicator Match │ Index patterns │ Overview │ Definition │ +│ Indicator Match │ Data view ID │ Overview │ Definition │ +│ Indicator Match │ Data view index pattern │ Overview │ Definition │ +│ Indicator Match │ Custom query │ Overview │ Definition │ +│ Indicator Match │ Filters │ Overview │ Definition │ +│ New Terms │ Fields │ Overview │ Definition │ +│ New Terms │ History Window Size │ Overview │ Definition │ +│ New Terms │ Index patterns │ Overview │ Definition │ +│ New Terms │ Data view ID │ Overview │ Definition │ +│ New Terms │ Data view index pattern │ Overview │ Definition │ +│ New Terms │ Custom query │ Overview │ Definition │ +│ New Terms │ Filters │ Overview │ Definition │ +│ ESQL │ ESQL query │ Overview │ Definition │ +│ ESQL │ Suppress alerts by │ Overview │ Definition │ +│ ESQL │ Suppress alerts for │ Overview │ Definition │ +│ ESQL │ If a suppression field is missing │ Overview │ Definition │ +``` + +## Scenarios + +### Rule installation notifications on the Rule Management page + +#### **Scenario: User is NOT notified when no prebuilt rules are installed and there are no prebuilt rules assets** + +**Automation**: 1 e2e test with mock rules + 1 integration test with mock rules for the /status endpoint. + +```Gherkin +Given no prebuilt rule assets exist in Kibana +And no prebuilt rules are installed +When user opens the Rule Management page +Then user should NOT see a CTA to install prebuilt rules +And user should NOT see a number of rules available to install +And user should NOT see a CTA to upgrade prebuilt rules +And user should NOT see a number of rules available to upgrade +And user should NOT see the Rule Updates table +``` + +#### **Scenario: User is NOT notified when all prebuilt rules are installed and up to date** + +**Automation**: 1 e2e test with mock rules + 1 integration test with mock rules for the /status endpoint. + +```Gherkin +Given the latest prebuilt rule assets exist in Kibana +And all the latest prebuilt rules from those rule assets are installed +When user opens the Rule Management page +Then user should NOT see a CTA to install prebuilt rules +And user should NOT see a number of rules available to install +And user should NOT see a CTA to upgrade prebuilt rules +And user should NOT see a number of rules available to upgrade +And user should NOT see the Rule Updates table +``` + +#### **Scenario: User is notified when no prebuilt rules are installed and there are rules available to install** + +**Automation**: 1 e2e test with mock rules + 1 integration test with mock rules for the /status endpoint. + +```Gherkin +Given X prebuilt rule assets exist in Kibana +And no prebuilt rules are installed +And there are X prebuilt rules available to install +When user opens the Rule Management page +Then user should see a CTA to install prebuilt rules +And user should see a number of rules available to install (X) +And user should NOT see a CTA to upgrade prebuilt rules +And user should NOT see a number of rules available to upgrade +And user should NOT see the Rule Updates table +``` + +#### **Scenario: User is notified when some prebuilt rules can be installed** + +**Automation**: 1 e2e test with mock rules + 1 integration test with mock rules for the /status endpoint. + +```Gherkin +Given Y prebuilt rule assets exist in Kibana +And X (where X < Y) prebuilt rules are installed +And there are Y more prebuilt rules available to install +And for all X installed rules there are no new versions available +When user opens the Rule Management page +Then user should see a CTA to install prebuilt rules +And user should see the number of rules available to install (Y) +And user should NOT see a CTA to upgrade prebuilt rules +And user should NOT see a number of rules available to upgrade +And user should NOT see the Rule Updates table +``` + +#### **Scenario: User is notified when both rules to install and upgrade are available** + +**Automation**: 1 e2e test with mock rules + 1 integration test with mock rules for the /status endpoint. + +```Gherkin +Given Y prebuilt rule assets exist in Kibana +And X (where X < Y) prebuilt rules are installed +And Z (where Z < X) installed rules have matching prebuilt rule assets with higher version available +And for Z of the installed rules there are new versions available +When user opens the Rule Management page +Then user should see a CTA to install prebuilt rules +And user should see the number of rules available to install (Y) +And user should see a CTA to upgrade prebuilt rules +And user should see the number of rules available to upgrade (Z) +``` + +#### **Scenario: User is notified after a prebuilt rule gets deleted** + +**Automation**: 1 e2e test with mock rules + 1 integration test with mock rules for the /status endpoint. + +```Gherkin +Given X prebuilt rules are installed in Kibana +And there are no more prebuilt rules available to install +When user opens the Rule Management page +And user deletes Y prebuilt rules +Then user should see a CTA to install prebuilt rules +And user should see rules available to install +``` + +### Rule installation workflow: base cases + +#### **Scenario: User can install prebuilt rules one by one** + +**Automation**: 1 e2e test with mock rules + integration tests with mock rules that would test /status and /installation/\* endpoints in integration. + +```Gherkin +Given X prebuilt rule assets exist in Kibana +And no prebuilt rules are installed +When user opens the Add Rules page +Then prebuilt rules available for installation should be displayed in the table +When user installs one individual rule without previewing it +Then success message should be displayed after installation +And the installed rule should be removed from the table +When user navigates back to the Rule Management page +Then user should see a CTA to install prebuilt rules +And user should see the number of rules available to install decreased by 1 +``` + +#### **Scenario: User can install multiple prebuilt rules selected on the page** + +**Automation**: 1 e2e test with mock rules + integration tests with mock rules that would test /status and /installation/\* endpoints in integration. + +```Gherkin +Given X prebuilt rule assets exist in Kibana +And no prebuilt rules are installed +When user opens the Add Rules page +Then prebuilt rules available for installation should be displayed in the table +When user selects rules +Then user should see a CTA to install number of rules +When user clicks the CTA +Then success message should be displayed after installation +And all the installed rules should be removed from the table +When user navigates back to the Rule Management page +Then user should see a CTA to install prebuilt rules +And user should see the number of rules available to install decreased by number of installed rules + +Examples: + | Y | + | a few rules on the page, e.g. 2 | + | all rules on the page, e.g. 12 | +``` + +#### **Scenario: User can install all available prebuilt rules at once** + +**Automation**: 1 e2e test with mock rules + integration tests with mock rules that would test /status and /installation/\* endpoints in integration. + +```Gherkin +Given X prebuilt rule assets exist in Kibana +And no prebuilt rules are installed +When user opens the Add Rules page +Then prebuilt rules available for installation should be displayed in the table +When user installs all rules +Then success message should be displayed after installation +And all the rules should be removed from the table +And user should see a message indicating that all available rules have been installed +And user should see a CTA that leads to the Rule Management page +When user clicks on the CTA +Then user should be navigated back to Rule Management page +And user should NOT see a CTA to install prebuilt rules +And user should NOT see a number of rules available to install +``` + +#### **Scenario: Empty screen is shown when all prebuilt rules are installed** + +**Automation**: 1 e2e test with mock rules + 1 integration test. + +```Gherkin +Given all the available prebuilt rules are installed in Kibana +When user opens the Add Rules page +Then user should see a message indicating that all available rules have been installed +And user should see a CTA that leads to the Rule Management page +``` + +#### **Scenario: User can preview rules available for installation** + +**Automation**: 1 e2e test + +```Gherkin +Given 2 prebuilt rule assets exist in Kibana +And no prebuilt rules are installed +When user opens the Add Rules page +Then all rules available for installation should be displayed in the table +When user opens the rule preview for the 1st rule +Then the preview should open +When user closes the preview +Then it should disappear +``` + +#### **Scenario: User can install a rule using the rule preview** + +**Automation**: 1 e2e test + +```Gherkin +Given 2 prebuilt rule assets exist in Kibana +And no prebuilt rules are installed +When user opens the Add Rules page +Then all rules available for installation should be displayed in the table +When user opens the rule preview for the rule +Then the preview should open +When user installs the rule using a CTA in the rule preview +Then the rule should be installed +And a success message should be displayed after installation +And the rule should be removed from the Add Rules table +When user navigates back to the Rule Management page +Then user should see a CTA to install prebuilt rules +And user should see the number of rules available to install as initial number minus 1 +``` + +#### **Scenario: User can see correct rule information in preview before installing** + +**Automation**: 1 e2e test + +```Gherkin +Given X prebuilt rule assets exist in Kibana +And no prebuilt rules are installed +When user opens the Add Rules page +Then all X rules available for installation should be displayed in the table +When user opens a rule preview for any rule +Then the preview should appear +And all properties of a rule should be displayed in the correct tab and section of the preview (see examples of rule properties above) +``` + +#### **Scenario: Optional tabs and sections without content should be hidden in preview before installing** + +**Automation**: 1 e2e test + +```Gherkin +Given 1 prebuilt rule assets exist in Kibana +And no prebuilt rules are installed +And this rule has neither Setup guide nor Investigation guide +When user opens the Add Rules page +Then all rules available for installation should be displayed in the table +When user opens the rule preview for this rule +Then the preview should open +And the Setup Guide section should NOT be displayed in the Overview tab +And the Investigation Guide tab should NOT be displayed +``` + +### Rule installation workflow: filtering, sorting, pagination + +TODO: add scenarios https://github.com/elastic/kibana/issues/166215 + +### Rule installation workflow: misc cases + +#### **Scenario: User opening the Add Rules page sees a loading skeleton until the package installation is completed** + +**Automation**: unit tests. + +```Gherkin +Given prebuilt rules package is not installed +When user opens the Add Rules page +Then user should see a loading skeleton until the package installation is completed +``` + +#### **Scenario: User can navigate from the Add Rules page to the Rule Management page via breadcrumbs** + +**Automation**: 1 e2e test. + +```Gherkin +Given user is on the Add Rules page +When user navigates to the Rule Management page via breadcrumbs +Then the Rule Management page should be displayed +``` + +### Rule installation via the Prebuilt rules API + +There's a legacy prebuilt rules API and a new one. Both should be tested against two types of the package: with and without historical rule versions. + +#### **Scenario: API can install all prebuilt rules** + +**Automation**: 8 integration tests with mock rules: 4 examples below \* 2 (we split checking API response and installed rules into two different tests). + +```Gherkin +Given the package is installed +And the package contains N rules +When user installs all rules via install +Then the endpoint should return success response (HTTP 200 code) with +And N rule objects should be created +And each rule object should have correct id and version + +Examples: + | package_type | api | install_response | + | with historical versions | legacy | installed: N, updated: 0 | + | w/o historical versions | legacy | installed: N, updated: 0 | + | with historical versions | new | total: N, succeeded: N | + | w/o historical versions | new | total: N, succeeded: N | +``` + +Notes: + +- Legacy API: + - install: `PUT /api/detection_engine/rules/prepackaged` +- New API: + - install: `POST /internal/detection_engine/prebuilt_rules/installation/_perform` + +#### **Scenario: API can install prebuilt rules that are not yet installed** + +**Automation**: 4 integration tests with mock rules. + +```Gherkin +Given the package is installed +And the package contains N rules +When user installs all rules via install +And deletes one of the installed rules +And gets prebuilt rules status via status +Then the endpoint should return successful response (HTTP 200 code) with +When user installs all rules via install again +Then the endpoint should return successful response (HTTP 200 code) with + +Examples: + | package_type | api | status_response | install_response | + | with historical versions | legacy | not_installed: 1 | installed: 1, updated: 0 | + | w/o historical versions | legacy | not_installed: 1 | installed: 1, updated: 0 | + | with historical versions | new | to_install: 1 | total: 1, succeeded: 1 | + | w/o historical versions | new | to_install: 1 | total: 1, succeeded: 1 | +``` + +Notes: + +- Legacy API: + - install: `PUT /api/detection_engine/rules/prepackaged` + - status: `GET /api/detection_engine/rules/prepackaged/_status` +- New API: + - install: `POST /internal/detection_engine/prebuilt_rules/installation/_perform` + - status: `GET /internal/detection_engine/prebuilt_rules/status` + + +#### **Scenario: API does not install prebuilt rules if they are up to date** + +**Automation**: 4 integration tests with mock rules. + +```Gherkin +Given the package is installed +And the package contains N rules +When user installs all rules via install +And user gets prebuilt rules status via status +Then the endpoint should return successful response (HTTP 200 code) with +When user calls install +Then the endpoint should return successful response (HTTP 200 code) with +When user calls upgrade +Then the endpoint should return successful response (HTTP 200 code) with + +Examples: + | package_type | api | status_response | install_response | upgrade_response | + | with historical versions | legacy | not_installed: 0, not_updated: 0 | installed: 0, updated: 0 | installed: 0, updated: 0 | + | w/o historical versions | legacy | not_installed: 0, not_updated: 0 | installed: 0, updated: 0 | installed: 0, updated: 0 | + | with historical versions | new | to_install: 0, to_upgrade: 0 | total: 0, succeeded: 0 | total: 0, succeeded: 0 | + | w/o historical versions | new | to_install: 0, to_upgrade: 0 | total: 0, succeeded: 0 | total: 0, succeeded: 0 | +``` + +Notes: + +- Legacy API: + - install: `PUT /api/detection_engine/rules/prepackaged` + - upgrade: `PUT /api/detection_engine/rules/prepackaged` + - status: `GET /api/detection_engine/rules/prepackaged/_status` +- New API: + - install: `POST /internal/detection_engine/prebuilt_rules/installation/_perform` + - upgrade: `POST /internal/detection_engine/prebuilt_rules/upgrade/_perform` + - status: `GET /internal/detection_engine/prebuilt_rules/status` + +### Error handling + +#### **Scenario: Error is handled when any installation operation on prebuilt rules fails** + +**Automation**: e2e test with mock rules + +```Gherkin +When user is prebuilt rules +And this operation fails +Then user should see an error message + +Examples: + | operation | + | installing all | + | installing selected | + | installing individual | +``` + +### Authorization / RBAC + +#### **Scenario: User with read privileges on Security Solution cannot install prebuilt rules** + +**Automation**: 1 e2e test with mock rules + 3 integration tests with mock rules for the status and installation endpoints. + +```Gherkin +Given user with "Security: read" privileges on Security Solution +And prebuilt rule assets exist in Kibana +And no prebuilt rules are installed +When user opens the Add Rules page +Then user should see prebuilt rules available to install +But user should not be able to install them +``` \ No newline at end of file diff --git a/x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/package_installation_and_upgrade.md b/x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/package_installation_and_upgrade.md new file mode 100644 index 0000000000000..57e16684facca --- /dev/null +++ b/x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/package_installation_and_upgrade.md @@ -0,0 +1,165 @@ +# Prebuilt Rules Package Installation and Upgrade + +This is a test plan for the workflows of installing and updating the Prebuilt Rules package. + +> For the test plans for installing and upgrading prebuilt rules, see [Installation of Prebuilt Rules](./installation.md) and [Upgrade of Prebuilt Rules](./upgrade.md). + +Status: `in progress`. The current test plan matches [Rule Immutability/Customization Milestone 3 epic](https://github.com/elastic/kibana/issues/174168). + +## Table of Contents + +- [Useful information](#useful-information) + - [Tickets](#tickets) + - [Terminology](#terminology) + - [Assumptions](#assumptions) + - [Non-functional requirements](#non-functional-requirements) + - [Functional requirements](#functional-requirements) +- [Scenarios](#scenarios) + - [Package installation](#package-installation) + - [**Scenario: Package is installed via Fleet**](#scenario-package-is-installed-via-fleet) + - [**Scenario: Package is installed via bundled Fleet package in Kibana**](#scenario-package-is-installed-via-bundled-fleet-package-in-kibana) + - [**Scenario: Large package can be installed on a small Kibana instance**](#scenario-large-package-can-be-installed-on-a-small-kibana-instance) + - [Scenarios for the real package](#scenarios-for-the-real-package) + - [**Scenario: User can install prebuilt rules from scratch, then install new rules and upgrade existing rules from the new package**](#scenario-user-can-install-prebuilt-rules-from-scratch-then-install-new-rules-and-upgrade-existing-rules-from-the-new-package) + - [Kibana upgrade](#kibana-upgrade) + - [**Scenario: User can use prebuilt rules after upgrading Kibana from version A to B**](#scenario-user-can-use-prebuilt-rules-after-upgrading-kibana-from-version-a-to-b) + +## Useful information + +### Tickets + +- [Rule Immutability/Customization epic](https://github.com/elastic/security-team/issues/1974)(internal) + +**Milestone 3 - Prebuilt Rules Customization:** +- [Milestone 3 epic ticket](https://github.com/elastic/kibana/issues/174168) +- [Tests for prebuilt rule upgrade workflow #202078](https://github.com/elastic/kibana/issues/202078) + +**Milestone 2:** +- [Ensure full test coverage for existing workflows of installing and upgrading prebuilt rules](https://github.com/elastic/kibana/issues/148176) +- [Write test plan and add test coverage for the new workflows of installing and upgrading prebuilt rules](https://github.com/elastic/kibana/issues/148192) + +### Terminology + +- **EPR**: [Elastic Package Registry](https://github.com/elastic/package-registry), service that hosts our **Package**. + +- **Package**: `security_detection_engine` Fleet package that we use to distribute prebuilt detection rules in the form of `security-rule` assets (saved objects). + +- **Real package**: actual latest stable package distributed and pulled from EPR via Fleet. + +- **Mock rules**: `security-rule` assets that are indexed into the `.kibana_security_solution` index directly in the test setup, either by using the ES client _in integration tests_ or by an API request _in Cypress tests_. + +- **Air-gapped environment**: an environment where Kibana doesn't have access to the internet. In general, EPR is not available in such environments, except the cases when the user runs a custom EPR inside the environment. + +- **CTA**: "call to action", usually a button, a link, or a callout message with a button, etc, that invites the user to do some action. + - CTA to install prebuilt rules - at this moment, it's a link button with a counter (implemented) and a callout with a link button (not yet implemented) on the Rule Management page. + - CTA to upgrade prebuilt rules - at this moment, it's a tab with a counter (implemented) and a callout with a link button (not yet implemented) on the Rule Management page. + +### Assumptions + +- Below scenarios only apply to prebuilt detection rules. +- Users should be able to install and upgrade prebuilt rules on the `Basic` license and higher. +- EPR is available for fetching the package unless explicitly indicated otherwise. +- Only the latest **stable** package is checked for installation/upgrade and pre-release packages are ignored. + +### Non-functional requirements + +- Package installation, rule installation and rule upgrade workflows should work: + - regardless of the package type: with historical rule versions or without; + - regardless of the package registry availability: i.e., they should also work in air-gapped environments. +- Rule installation and upgrade workflows should work with packages containing up to 15000 historical rule versions. This is the max number of versions of all rules in the package. This limit is enforced by Fleet. +- Kibana should not crash with Out Of Memory exception during package installation. +- For test purposes, it should be possible to use detection rules package versions lower than the latest. + +### Functional requirements + +- User should be able to install prebuilt rules with and without previewing what exactly they would install (rule properties). +- User should be able to upgrade prebuilt rules with and without previewing what updates they would apply (rule properties of target rule versions). + +## Scenarios + +### Package installation + +#### **Scenario: Package is installed via Fleet** + +**Automation**: 2 e2e tests that install the real package. + +```Gherkin +Given the prebuilt rules package is not installed +When user opens any Security Solution page +Then the package gets installed in the background from EPR +``` + +#### **Scenario: Package is installed via bundled Fleet package in Kibana** + +**Automation**: 2 integration tests. + +```Gherkin +Given the package is not installed +And user is in an air-gapped environment +When user opens any Security Solution page +Then the package gets installed in the background from packages bundled into Kibana +``` + +#### **Scenario: Large package can be installed on a memory restricted Kibana instance** + +**Automation**: 1 integration test. + +```Gherkin +Given the package is not installed +And the package contains the largest amount of historical rule versions (15000) +And the Kibana instance has a memory heap size of 700 Mb (see note below) +When user opens any Security Solution page +Then the package is installed without Kibana crashing with an Out Of Memory error +``` + +**Note**: 600 Mb seems to always crash Kibana with an OOM error. 700 Mb runs with no issues in the Flaky test runner with 100 iterations: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/2215. + +### Scenarios for the real package + +#### **Scenario: User can install prebuilt rules from scratch, then install new rules and upgrade existing rules from the new package** + +**Automation**: 1 integration test with real packages. + +```Gherkin +Given there are two package versions: A and B where A < B +And the package of A version is installed +When user calls the status endpoint +Then it should return a 200 response with some number of rules to install and 0 rules to upgrade +When user calls the installation/_review endpoint +Then it should return a 200 response matching the response of the status endpoint +When user calls the installation/_perform_ endpoint +Then it should return a 200 response matching the response of the status endpoint +And rules returned in this response should exist as alert saved objects +When user installs version B of the package +Then it should be installed successfully +When user calls the status endpoint +Then it should return a 200 response with some number of new rules to install and some number of rules to upgrade +When user calls the installation/_review endpoint +Then it should return a 200 response matching the response of the status endpoint +When user calls the installation/_perform_ endpoint +Then rules returned in this response should exist as alert saved objects +When user calls the upgrade/_review endpoint +Then it should return a 200 response matching the response of the status endpoint +When user calls the upgrade/_perform_ endpoint +Then rules returned in this response should exist as alert saved objects +``` + +### Kibana upgrade + +#### **Scenario: User can use prebuilt rules after upgrading Kibana from version A to B** + +**Automation**: not automated, manual testing required. + +```Gherkin +Given user is upgrading Kibana from version to version +And the version Kibana instance has already installed prebuilt rules +When the Kibana upgrade is complete +Then user should be able to install new prebuilt rules +And delete installed prebuilt rules +And upgrade installed prebuilt rules that have newer versions in Kibana version + +Examples: + | A | B | + | 8.7 | 8.9.0 | + | 7.17.x | 8.9.0 | +``` diff --git a/x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md b/x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/upgrade.md similarity index 55% rename from x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md rename to x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/upgrade.md index e5479ec502865..4beb517f9598a 100644 --- a/x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md +++ b/x-pack/solutions/security/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/upgrade.md @@ -1,8 +1,8 @@ -# Installation and Upgrade of Prebuilt Rules +# Upgrade of Prebuilt Rules -This is a test plan for the workflows of installing and upgrading prebuilt rules. +This is a test plan for the workflow of upgrading prebuilt rules. -Status: `in progress`. The current test plan matches `Milestone 2` of the [Rule Immutability/Customization](https://github.com/elastic/security-team/issues/1974) epic. It does not cover any past functionality that was removed or functionality to be implemented in the future. The plan is about to change in the future Milestones. +Status: `in progress`. The current test plan matches [Rule Immutability/Customization Milestone 3 epic](https://github.com/elastic/kibana/issues/174168). ## Table of Contents @@ -12,84 +12,73 @@ Status: `in progress`. The current test plan matches `Milestone 2` of the [Rule - [Assumptions](#assumptions) - [Non-functional requirements](#non-functional-requirements) - [Functional requirements](#functional-requirements) -- [Scenarios](#scenarios) - - - [Package installation](#package-installation) - - [**Scenario: Package is installed via Fleet**](#scenario-package-is-installed-via-fleet) - - [**Scenario: Package is installed via bundled Fleet package in Kibana**](#scenario-package-is-installed-via-bundled-fleet-package-in-kibana) - - [**Scenario: Large package can be installed on a small Kibana instance**](#scenario-large-package-can-be-installed-on-a-small-kibana-instance) - - [Rule installation and upgrade via the Prebuilt rules API](#rule-installation-and-upgrade-via-the-prebuilt-rules-api) - - [**Scenario: API can install all prebuilt rules**](#scenario-api-can-install-all-prebuilt-rules) - - [**Scenario: API can install prebuilt rules that are not yet installed**](#scenario-api-can-install-prebuilt-rules-that-are-not-yet-installed) - - [**Scenario: API can upgrade prebuilt rules that are outdated**](#scenario-api-can-upgrade-prebuilt-rules-that-are-outdated) - - [**Scenario: API does not install or upgrade prebuilt rules if they are up to date**](#scenario-api-does-not-install-or-upgrade-prebuilt-rules-if-they-are-up-to-date) - - [Scenarios for the real package](#scenarios-for-the-real-package) - - [**Scenario: User can install prebuilt rules from scratch, then install new rules and upgrade existing rules from the new package**](#scenario-user-can-install-prebuilt-rules-from-scratch-then-install-new-rules-and-upgrade-existing-rules-from-the-new-package) - - [Rule installation and upgrade notifications on the Rule Management page](#rule-installation-and-upgrade-notifications-on-the-rule-management-page) - - [**Scenario: User is NOT notified when no prebuilt rules are installed and there are no prebuilt rules assets**](#scenario-user-is-not-notified-when-no-prebuilt-rules-are-installed-and-there-are-no-prebuilt-rules-assets) - - [**Scenario: User is NOT notified when all prebuilt rules are installed and up to date**](#scenario-user-is-not-notified-when-all-prebuilt-rules-are-installed-and-up-to-date) - - [**Scenario: User is notified when no prebuilt rules are installed and there are rules available to install**](#scenario-user-is-notified-when-no-prebuilt-rules-are-installed-and-there-are-rules-available-to-install) - - [**Scenario: User is notified when some prebuilt rules can be installed**](#scenario-user-is-notified-when-some-prebuilt-rules-can-be-installed) - - [**Scenario: User is notified when some prebuilt rules can be upgraded**](#scenario-user-is-notified-when-some-prebuilt-rules-can-be-upgraded) - - [**Scenario: User is notified when both rules to install and upgrade are available**](#scenario-user-is-notified-when-both-rules-to-install-and-upgrade-are-available) - - [**Scenario: User is notified after a prebuilt rule gets deleted**](#scenario-user-is-notified-after-a-prebuilt-rule-gets-deleted) - - [Rule installation workflow: base cases](#rule-installation-workflow-base-cases) - - [**Scenario: User can install prebuilt rules one by one**](#scenario-user-can-install-prebuilt-rules-one-by-one) - - [**Scenario: User can install multiple prebuilt rules selected on the page**](#scenario-user-can-install-multiple-prebuilt-rules-selected-on-the-page) - - [**Scenario: User can install all available prebuilt rules at once**](#scenario-user-can-install-all-available-prebuilt-rules-at-once) - - [**Scenario: Empty screen is shown when all prebuilt rules are installed**](#scenario-empty-screen-is-shown-when-all-prebuilt-rules-are-installed) - - [**Scenario: User can preview rules available for installation**](#scenario-user-can-preview-rules-available-for-installation) - - [**Scenario: User can install a rule using the rule preview**](#scenario-user-can-install-a-rule-using-the-rule-preview) - - [**Scenario: User can see correct rule information in preview before installing**](#scenario-user-can-see-correct-rule-information-in-preview-before-installing) - - [**Scenario: Tabs and sections without content should be hidden in preview before installing**](#scenario-tabs-and-sections-without-content-should-be-hidden-in-preview-before-installing) - - [Rule installation workflow: filtering, sorting, pagination](#rule-installation-workflow-filtering-sorting-pagination) - - [Rule installation workflow: misc cases](#rule-installation-workflow-misc-cases) - - [**Scenario: User opening the Add Rules page sees a loading skeleton until the package installation is completed**](#scenario-user-opening-the-add-rules-page-sees-a-loading-skeleton-until-the-package-installation-is-completed) - - [**Scenario: User can navigate from the Add Rules page to the Rule Management page via breadcrumbs**](#scenario-user-can-navigate-from-the-add-rules-page-to-the-rule-management-page-via-breadcrumbs) - - [Rule upgrade workflow: base cases](#rule-upgrade-workflow-base-cases) - - [**Scenario: User can upgrade prebuilt rules one by one**](#scenario-user-can-upgrade-prebuilt-rules-one-by-one) - - [**Scenario: User can upgrade multiple prebuilt rules selected on the page**](#scenario-user-can-upgrade-multiple-prebuilt-rules-selected-on-the-page) - - [**Scenario: User can upgrade all available prebuilt rules at once**](#scenario-user-can-upgrade-all-available-prebuilt-rules-at-once) - - [**Scenario: User can preview rules available for upgrade**](#scenario-user-can-preview-rules-available-for-upgrade) - - [**Scenario: User can upgrade a rule using the rule preview**](#scenario-user-can-upgrade-a-rule-using-the-rule-preview) - - [**Scenario: User can see correct rule information in preview before upgrading**](#scenario-user-can-see-correct-rule-information-in-preview-before-upgrading) - - [**Scenario: Tabs and sections without content should be hidden in preview before upgrading**](#scenario-tabs-and-sections-without-content-should-be-hidden-in-preview-before-upgrading) - - [Rule upgrade workflow: filtering, sorting, pagination](#rule-upgrade-workflow-filtering-sorting-pagination) - - [Rule upgrade workflow: viewing rule changes in JSON diff view](#rule-upgrade-workflow-viewing-rule-changes-in-json-diff-view) - - [**Scenario: User can see changes in a side-by-side JSON diff view**](#scenario-user-can-see-changes-in-a-side-by-side-json-diff-view) - - [**Scenario: User can see precisely how property values would change after upgrade**](#scenario-user-can-see-precisely-how-property-values-would-change-after-upgrade) - - [**Scenario: Rule actions and exception lists should not be shown as modified**](#scenario-rule-actions-and-exception-lists-should-not-be-shown-as-modified) - - [**Scenario: Dynamic properties should not be included in preview**](#scenario-dynamic-properties-should-not-be-included-in-preview) - - [**Scenario: Technical properties should not be included in preview**](#scenario-technical-properties-should-not-be-included-in-preview) - - [**Scenario: Properties with semantically equal values should not be shown as modified**](#scenario-properties-with-semantically-equal-values-should-not-be-shown-as-modified) - - [**Scenario: Unchanged sections of a rule should be hidden by default**](#scenario-unchanged-sections-of-a-rule-should-be-hidden-by-default) - - [**Scenario: Properties should be sorted alphabetically**](#scenario-properties-should-be-sorted-alphabetically) - - [Rule upgrade workflow: viewing rule changes in per-field diff view](#rule-upgrade-workflow-viewing-rule-changes-in-per-field-diff-view) - - [**Scenario: User can see changes in a side-by-side per-field diff view**](#scenario-user-can-see-changes-in-a-side-by-side-per-field-diff-view) - - [**Scenario: Field groupings should be rendered together in the same accordion panel**](#scenario-field-groupings-should-be-rendered-together-in-the-same-accordion-panel) - - [**Scenario: Undefined values are displayed with empty diffs**](#scenario-undefined-values-are-displayed-with-empty-diffs) - - [**Scenario: Field diff components have the same grouping and order as in rule details overview**](#scenario-field-diff-components-have-the-same-grouping-and-order-as-in-rule-details-overview) - - [Rule upgrade workflow: preserving rule bound data](#rule-upgrade-workflow-preserving-rule-bound-data) - - [**Scenario: Rule bound data is preserved after upgrading a rule to a newer version with the same rule type**](#scenario-rule-bound-data-is-preserved-after-upgrading-a-rule-to-a-newer-version-with-the-same-rule-type) - - [**Scenario: Rule bound data is preserved after upgrading a rule to a newer version with a different rule type**](#scenario-rule-bound-data-is-preserved-after-upgrading-a-rule-to-a-newer-version-with-a-different-rule-type) - - [Rule upgrade workflow: misc cases](#rule-upgrade-workflow-misc-cases) - - [**Scenario: User doesn't see the Rule Updates tab until the package installation is completed**](#scenario-user-doesnt-see-the-rule-updates-tab-until-the-package-installation-is-completed) - - [Error handling](#error-handling) - - [**Scenario: Error is handled when any operation on prebuilt rules fails**](#scenario-error-is-handled-when-any-operation-on-prebuilt-rules-fails) - - [Authorization / RBAC](#authorization--rbac) - - [**Scenario: User with read privileges on Security Solution cannot install prebuilt rules**](#scenario-user-with-read-privileges-on-security-solution-cannot-install-prebuilt-rules) - - [**Scenario: User with read privileges on Security Solution cannot upgrade prebuilt rules**](#scenario-user-with-read-privileges-on-security-solution-cannot-upgrade-prebuilt-rules) - - [Kibana upgrade](#kibana-upgrade) - - [**Scenario: User can use prebuilt rules after upgrading Kibana from version A to B**](#scenario-user-can-use-prebuilt-rules-after-upgrading-kibana-from-version-a-to-b) + - [Scenarios](#scenarios) + - [Rule installation and upgrade notifications on the Rule Management page](#rule-installation-and-upgrade-notifications-on-the-rule-management-page) + - [**Scenario: User is NOT notified when all installed prebuilt rules are up to date**](#scenario-user-is-not-notified-when-all-installed-prebuilt-rules-are-up-to-date) + - [**Scenario: User is notified when some prebuilt rules can be upgraded**](#scenario-user-is-notified-when-some-prebuilt-rules-can-be-upgraded) + - [**Scenario: User is notified when both rules to install and upgrade are available**](#scenario-user-is-notified-when-both-rules-to-install-and-upgrade-are-available) + - [Rule upgrade workflow: individual upgrade from Rule Updates table](#rule-upgrade-workflow-individual-and-bulk-updates-from-rule-updates-table) + - [**Scenario: User can upgrade conflict-free prebuilt rules one by one**](#scenario-user-can-upgrade-conflict-free-prebuilt-rules-one-by-one) + - [**Scenario: User cannot upgrade prebuilt rules one by one from Rules Update table if they have conflicts**](#scenario-user-cannot-upgrade-prebuilt-rules-one-by-one-from-rules-update-table-if-they-have-conflicts) + - [Rule upgrade workflow: bulk upgrade from Rule Updates table](#rule-upgrade-workflow-individual-and-bulk-updates-from-rule-updates-table) + - [**Scenario: User can upgrade multiple conflict-free prebuilt rules selected on the page**](#scenario-user-can-upgrade-multiple-conflict-free-prebuilt-rules-selected-on-the-page) + - [**Scenario: User cannot upgrade multiple prebuilt rules selected on the page when they have upgrade conflicts**](#scenario-user-cannot-upgrade-multiple-prebuilt-rules-selected-on-the-page-when-they-have-upgrade-conflicts) + - [**Scenario: User can upgrade all available conflict-free prebuilt rules at once**](#scenario-user-can-upgrade-all-available-conflict-free-prebuilt-rules-at-once) + - [**Scenario: User cannot upgrade all prebuilt rules at once if they have upgrade conflicts**](#scenario-user-cannot-upgrade-all-prebuilt-rules-at-once-if-they-have-upgrade-conflicts) + - [**Scenario: User can upgrade only conflict-free rules when a mix of rules with and without conflicts are selected for upgrade in the Rules Table**](#scenario-user-can-upgrade-only-conflict-free-rules-when-a-mix-of-rules-with-and-without-conflicts-are-selected-for-upgrade-in-the-rules-table) + - [**Scenario: User can upgrade only conflict-free rules when user attempts to upgrade all rules and only a subset contains upgrade conflicts**](#scenario-user-can-upgrade-only-conflict-free-rules-when-user-attempts-to-upgrade-all-rules-and-only-a-subset-contains-upgrade-conflicts) + - [Rule upgrade workflow: upgrading rules with rule type change](#rule-upgrade-workflow-upgrading-rules-with-rule-type-change) + - [**Scenario: User can upgrade rule with rule type change individually**](#scenario-user-can-upgrade-rule-with-rule-type-change-individually) + - [**Scenario: User can bulk upgrade selected rules with rule type changes**](#scenario-user-can-bulk-upgrade-selected-rules-with-rule-type-changes) + - [**Scenario: User can bulk upgrade all rules with rule type changes**](#scenario-user-can-bulk-upgrade-all-rules-with-rule-type-changes) + - [Rule upgrade workflow: rule previews](#rule-upgrade-workflow-rule-previews) + - [**Scenario: User can preview rules available for upgrade**](#scenario-user-can-preview-rules-available-for-upgrade) + - [**Scenario: User can upgrade a rule using the rule preview**](#scenario-user-can-upgrade-a-rule-using-the-rule-preview) + - [**Scenario: User can see correct rule information in preview before upgrading**](#scenario-user-can-see-correct-rule-information-in-preview-before-upgrading) + - [**Scenario: Tabs and sections without content should be hidden in preview before upgrading**](#scenario-tabs-and-sections-without-content-should-be-hidden-in-preview-before-upgrading) + - [Rule upgrade workflow: filtering, sorting, pagination](#rule-upgrade-workflow-filtering-sorting-pagination) + - [MILESTONE 2 (Legacy) - Rule upgrade workflow: viewing rule changes in JSON diff view](#milestone-2-legacy---rule-upgrade-workflow-viewing-rule-changes-in-json-diff-view) + - [**Scenario: User can see changes in a side-by-side JSON diff view**](#scenario-user-can-see-changes-in-a-side-by-side-json-diff-view) + - [**Scenario: User can see precisely how property values would change after upgrade**](#scenario-user-can-see-precisely-how-property-values-would-change-after-upgrade) + - [**Scenario: Rule actions and exception lists should not be shown as modified**](#scenario-rule-actions-and-exception-lists-should-not-be-shown-as-modified) + - [**Scenario: Dynamic properties should not be included in preview**](#scenario-dynamic-properties-should-not-be-included-in-preview) + - [**Scenario: Technical properties should not be included in preview**](#scenario-technical-properties-should-not-be-included-in-preview) + - [**Scenario: Properties with semantically equal values should not be shown as modified**](#scenario-properties-with-semantically-equal-values-should-not-be-shown-as-modified) + - [**Scenario: Unchanged sections of a rule should be hidden by default**](#scenario-unchanged-sections-of-a-rule-should-be-hidden-by-default) + - [**Scenario: Properties should be sorted alphabetically**](#scenario-properties-should-be-sorted-alphabetically) + - [MILESTONE 2 (Legacy) - Rule upgrade workflow: viewing rule changes in per-field diff view](#milestone-2-legacy---rule-upgrade-workflow-viewing-rule-changes-in-per-field-diff-view) + - [**Scenario: User can see changes in a side-by-side per-field diff view**](#scenario-user-can-see-changes-in-a-side-by-side-per-field-diff-view) + - [**Scenario: User can see changes when updated rule is a different rule type**](#scenario-user-can-see-changes-when-updated-rule-is-a-different-rule-type) + - [**Scenario: Field groupings should be rendered together in the same accordion panel**](#scenario-field-groupings-should-be-rendered-together-in-the-same-accordion-panel) + - [**Scenario: Undefined values are displayed with empty diffs**](#scenario-undefined-values-are-displayed-with-empty-diffs) + - [**Scenario: Field diff components have the same grouping and order as in rule details overview**](#scenario-field-diff-components-have-the-same-grouping-and-order-as-in-rule-details-overview) + - [Rule upgrade workflow: preserving rule bound data](#rule-upgrade-workflow-preserving-rule-bound-data) + - [**Scenario: Rule bound data is preserved after upgrading a rule to a newer version with the same rule type**](#scenario-rule-bound-data-is-preserved-after-upgrading-a-rule-to-a-newer-version-with-the-same-rule-type) + - [**Scenario: Rule bound data is preserved after upgrading a rule to a newer version with a different rule type**](#scenario-rule-bound-data-is-preserved-after-upgrading-a-rule-to-a-newer-version-with-a-different-rule-type) + - [Rule upgrade workflow: misc cases](#rule-upgrade-workflow-misc-cases) + - [**Scenario: User doesn't see the Rule Updates tab until the package installation is completed**](#scenario-user-doesnt-see-the-rule-updates-tab-until-the-package-installation-is-completed) + - [Error handling](#error-handling) + - [**Scenario: Error is handled when any upgrade operation on prebuilt rules fails**](#scenario-error-is-handled-when-any-upgrade-operation-on-prebuilt-rules-fails) + - [Rule upgrade via the Prebuilt rules API](#rule-upgrade-via-the-prebuilt-rules-api) + - [**Scenario: API can upgrade prebuilt rules that are outdated**](#scenario-api-can-upgrade-prebuilt-rules-that-are-outdated) + - [**Scenario: API does not upgrade prebuilt rules if they are up to date**](#scenario-api-does-not-upgrade-prebuilt-rules-if-they-are-up-to-date) + - [Authorization / RBAC](#authorization-rbac) + - [**Scenario: User with read privileges on Security Solution cannot upgrade prebuilt rules**](#scenario-user-with-read-privileges-on-security-solution-cannot-upgrade-prebuilt-rules) + ## Useful information ### Tickets - [Rule Immutability/Customization](https://github.com/elastic/security-team/issues/1974) epic + +**Milestone 3 - Prebuilt Rules Customization:** +- [Milestone 3 epic ticket](https://github.com/elastic/kibana/issues/174168) +- [Tests for prebuilt rule upgrade workflow #202078](https://github.com/elastic/kibana/issues/202078) + +**Milestone 2:** - [Ensure full test coverage for existing workflows of installing and upgrading prebuilt rules](https://github.com/elastic/kibana/issues/148176) - [Write test plan and add test coverage for the new workflows of installing and upgrading prebuilt rules](https://github.com/elastic/kibana/issues/148192) -- [Document the new UI for installing and upgrading prebuilt detection rules](https://github.com/elastic/security-docs/issues/3496) ### Terminology @@ -205,266 +194,15 @@ Examples: ## Scenarios -### Package installation - -#### **Scenario: Package is installed via Fleet** - -**Automation**: 2 e2e tests that install the real package. - -```Gherkin -Given the package is not installed -When user opens the Rule Management page -Then the package gets installed in the background from EPR -``` - -#### **Scenario: Package is installed via bundled Fleet package in Kibana** - -**Automation**: 2 integration tests. - -```Gherkin -Given the package is not installed -And user is in an air-gapped environment -When user opens the Rule Management page -Then the package gets installed in the background from packages bundled into Kibana -``` - -#### **Scenario: Large package can be installed on a small Kibana instance** - -**Automation**: 1 integration test. - -```Gherkin -Given the package is not installed -And the package contains the largest amount of historical rule versions (15000) -And the Kibana instance has a memory heap size of 700 Mb (see note below) -When user opens the Rule Management page -Then the package is installed without Kibana crashing with an Out Of Memory error -``` - -**Note**: 600 Mb seems to always crash Kibana with an OOM error. 700 Mb runs with no issues in the Flaky test runner with 100 iterations: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/2215. - -### Rule installation and upgrade via the Prebuilt rules API - -There's a legacy prebuilt rules API and a new one. Both should be tested against two types of the package: with and without historical rule versions. - -#### **Scenario: API can install all prebuilt rules** - -**Automation**: 8 integration tests with mock rules: 4 examples below \* 2 (we split checking API response and installed rules into two different tests). - -```Gherkin -Given the package is installed -And the package contains N rules -When user installs all rules via install -Then the endpoint should return 200 with -And N rule objects should be created -And each rule object should have correct id and version - -Examples: - | package_type | api | install_response | - | with historical versions | legacy | installed: N, updated: 0 | - | w/o historical versions | legacy | installed: N, updated: 0 | - | with historical versions | new | total: N, succeeded: N | - | w/o historical versions | new | total: N, succeeded: N | -``` - -Notes: - -- Legacy API: - - install: `PUT /api/detection_engine/rules/prepackaged` -- New API: - - install: `POST /internal/detection_engine/prebuilt_rules/installation/_perform` - -#### **Scenario: API can install prebuilt rules that are not yet installed** - -**Automation**: 4 integration tests with mock rules. - -```Gherkin -Given the package is installed -And the package contains N rules -When user installs all rules via install -And deletes one of the installed rules -And gets prebuilt rules status via status -Then the endpoint should return 200 with -When user installs all rules via install again -Then the endpoint should return 200 with - -Examples: - | package_type | api | status_response | install_response | - | with historical versions | legacy | not_installed: 1 | installed: 1, updated: 0 | - | w/o historical versions | legacy | not_installed: 1 | installed: 1, updated: 0 | - | with historical versions | new | to_install: 1 | total: 1, succeeded: 1 | - | w/o historical versions | new | to_install: 1 | total: 1, succeeded: 1 | -``` - -Notes: - -- Legacy API: - - install: `PUT /api/detection_engine/rules/prepackaged` - - status: `GET /api/detection_engine/rules/prepackaged/_status` -- New API: - - install: `POST /internal/detection_engine/prebuilt_rules/installation/_perform` - - status: `GET /internal/detection_engine/prebuilt_rules/status` - -#### **Scenario: API can upgrade prebuilt rules that are outdated** - -**Automation**: 4 integration tests with mock rules. - -```Gherkin -Given the package is installed -And the package contains N rules -When user installs all rules via install -And new X+1 version of a rule asset -And user gets prebuilt rules status via status -Then the endpoint should return 200 with -When user upgrades all rules via upgrade -Then the endpoint should return 200 with - -Examples: - | package_type | api | assets_update | status_response | upgrade_response | - | with historical versions | legacy | gets added | not_updated: 1 | installed: 0, updated: 1 | - | w/o historical versions | legacy | replaces X | not_updated: 1 | installed: 0, updated: 1 | - | with historical versions | new | gets added | to_upgrade: 1 | total: 1, succeeded: 1 | - | w/o historical versions | new | replaces X | to_upgrade: 1 | total: 1, succeeded: 1 | -``` +### Rule upgrade notifications on the Rule Management page -TODO: Check why for the legacy API Dmitrii has added 2 integration tests for `rule package with historical versions` instead of 1: - -- `should update outdated prebuilt rules when previous historical versions available` -- `should update outdated prebuilt rules when previous historical versions unavailable` - -(NOTE: the second scenario tests that, if a new version of a rule is released, it can upgrade the current instance of that rule even if the historical versions of that rule are no longer in the package) - -Notes: - -- Legacy API: - - install: `PUT /api/detection_engine/rules/prepackaged` - - upgrade: `PUT /api/detection_engine/rules/prepackaged` - - status: `GET /api/detection_engine/rules/prepackaged/_status` -- New API: - - install: `POST /internal/detection_engine/prebuilt_rules/installation/_perform` - - upgrade: `POST /internal/detection_engine/prebuilt_rules/upgrade/_perform` - - status: `GET /internal/detection_engine/prebuilt_rules/status` - -#### **Scenario: API does not install or upgrade prebuilt rules if they are up to date** - -**Automation**: 4 integration tests with mock rules. - -```Gherkin -Given the package is installed -And the package contains N rules -When user installs all rules via install -And user gets prebuilt rules status via status -Then the endpoint should return 200 with -When user calls install -Then the endpoint should return 200 with -When user calls upgrade -Then the endpoint should return 200 with - -Examples: - | package_type | api | status_response | install_response | upgrade_response | - | with historical versions | legacy | not_installed: 0, not_updated: 0 | installed: 0, updated: 0 | installed: 0, updated: 0 | - | w/o historical versions | legacy | not_installed: 0, not_updated: 0 | installed: 0, updated: 0 | installed: 0, updated: 0 | - | with historical versions | new | to_install: 0, to_upgrade: 0 | total: 0, succeeded: 0 | total: 0, succeeded: 0 | - | w/o historical versions | new | to_install: 0, to_upgrade: 0 | total: 0, succeeded: 0 | total: 0, succeeded: 0 | -``` - -Notes: - -- Legacy API: - - install: `PUT /api/detection_engine/rules/prepackaged` - - upgrade: `PUT /api/detection_engine/rules/prepackaged` - - status: `GET /api/detection_engine/rules/prepackaged/_status` -- New API: - - install: `POST /internal/detection_engine/prebuilt_rules/installation/_perform` - - upgrade: `POST /internal/detection_engine/prebuilt_rules/upgrade/_perform` - - status: `GET /internal/detection_engine/prebuilt_rules/status` - -### Scenarios for the real package - -#### **Scenario: User can install prebuilt rules from scratch, then install new rules and upgrade existing rules from the new package** - -**Automation**: 1 integration test with real packages. - -```Gherkin -Given there are two package versions: N-1 and N -And the package of N-1 version is installed -When user calls the status endpoint -Then it should return a 200 response with some number of rules to install and 0 rules to upgrade -When user calls the installation/_review endpoint -Then it should return a 200 response matching the response of the status endpoint -When user calls the installation/_perform_ endpoint -Then it should return a 200 response matching the response of the status endpoint -And rules returned in this response should exist as alert saved objects -When user installs the package of N version -Then it should be installed successfully -When user calls the status endpoint -Then it should return a 200 response with some number of new rules to install and some number of rules to upgrade -When user calls the installation/_review endpoint -Then it should return a 200 response matching the response of the status endpoint -When user calls the installation/_perform_ endpoint -Then rules returned in this response should exist as alert saved objects -When user calls the upgrade/_review endpoint -Then it should return a 200 response matching the response of the status endpoint -When user calls the upgrade/_perform_ endpoint -Then rules returned in this response should exist as alert saved objects -``` - -### Rule installation and upgrade notifications on the Rule Management page - -#### **Scenario: User is NOT notified when no prebuilt rules are installed and there are no prebuilt rules assets** - -**Automation**: 1 e2e test with mock rules + 1 integration test with mock rules for the /status endpoint. - -```Gherkin -Given no prebuilt rules are installed in Kibana -And no prebuilt rule assets exist -When user opens the Rule Management page -Then user should NOT see a CTA to install prebuilt rules -And user should NOT see a number of rules available to install -And user should NOT see a CTA to upgrade prebuilt rules -And user should NOT see a number of rules available to upgrade -And user should NOT see the Rule Updates table -``` - -#### **Scenario: User is NOT notified when all prebuilt rules are installed and up to date** +#### **Scenario: User is NOT notified when all installed prebuilt rules are up to date** **Automation**: 1 e2e test with mock rules + 1 integration test with mock rules for the /status endpoint. ```Gherkin Given all the latest prebuilt rules are installed in Kibana When user opens the Rule Management page -Then user should NOT see a CTA to install prebuilt rules -And user should NOT see a number of rules available to install -And user should NOT see a CTA to upgrade prebuilt rules -And user should NOT see a number of rules available to upgrade -And user should NOT see the Rule Updates table -``` - -#### **Scenario: User is notified when no prebuilt rules are installed and there are rules available to install** - -**Automation**: 1 e2e test with mock rules + 1 integration test with mock rules for the /status endpoint. - -```Gherkin -Given no prebuilt rules are installed in Kibana -And there are X prebuilt rules available to install -When user opens the Rule Management page -Then user should see a CTA to install prebuilt rules -And user should see a number of rules available to install (X) -And user should NOT see a CTA to upgrade prebuilt rules -And user should NOT see a number of rules available to upgrade -And user should NOT see the Rule Updates table -``` - -#### **Scenario: User is notified when some prebuilt rules can be installed** - -**Automation**: 1 e2e test with mock rules + 1 integration test with mock rules for the /status endpoint. - -```Gherkin -Given X prebuilt rules are installed in Kibana -And there are Y more prebuilt rules available to install -And for all X installed rules there are no new versions available -When user opens the Rule Management page -Then user should see a CTA to install prebuilt rules -And user should see the number of rules available to install (Y) And user should NOT see a CTA to upgrade prebuilt rules And user should NOT see a number of rules available to upgrade And user should NOT see the Rule Updates table @@ -500,242 +238,210 @@ And user should see a CTA to upgrade prebuilt rules And user should see the number of rules available to upgrade (Z) ``` -#### **Scenario: User is notified after a prebuilt rule gets deleted** +### Rule upgrade workflow: individual updates from Rule Updates table -**Automation**: 1 e2e test with mock rules + 1 integration test with mock rules for the /status endpoint. +#### **Scenario: User can upgrade conflict-free prebuilt rules one by one** + +**Automation**: 1 e2e test with mock rules + integration tests with mock rules that would test /status and /upgrade/\* endpoints in integration. ```Gherkin Given X prebuilt rules are installed in Kibana -And there are no more prebuilt rules available to install -When user opens the Rule Management page -And user deletes Y prebuilt rules -Then user should see a CTA to install prebuilt rules -And user should see the number of rules available to install (Y) +And for Y of the installed rules there are new versions available +When user is on the Rule Updates table +Then Y rules available for upgrade should be displayed in the table +When user upgrades one individual rule without previewing it +Then success message should be displayed after upgrade +And the upgraded rule should be removed from the table +And user should see the number of rules available to upgrade decreased by 1 ``` -### Rule installation workflow: base cases - -#### **Scenario: User can install prebuilt rules one by one** +#### **Scenario: User cannot upgrade prebuilt rules one by one from Rules Update table if they have conflicts** -**Automation**: 1 e2e test with mock rules + integration tests with mock rules that would test /status and /installation/\* endpoints in integration. +**Automation**: 1 e2e test with mock rules ```Gherkin -Given no prebuilt rules are installed in Kibana -And there are X prebuilt rules available to install -When user opens the Add Rules page -Then prebuilt rules available for installation should be displayed in the table -When user installs one individual rule without previewing it -Then success message should be displayed after installation -And the installed rule should be removed from the table -When user navigates back to the Rule Management page -Then user should see a CTA to install prebuilt rules -And user should see the number of rules available to install decreased by 1 +Given X prebuilt rules are installed in Kibana +And for Y of the installed rules there are new versions available +And user is on the Rule Updates table +Then Y rules available for upgrade should be displayed in the table +And for Z (where Z < Y) of the rules with upgrades there are upgrade conflicts +Then for those Z rules the Upgrade Rule button should be disabled +And the user should not be able to upgrade them directly from the table +And there should be a message/tooltip indicating why the rule cannot be upgraded directly ``` -#### **Scenario: User can install multiple prebuilt rules selected on the page** +### Rule upgrade workflow: bulk updates from Rule Updates table -**Automation**: 1 e2e test with mock rules + integration tests with mock rules that would test /status and /installation/\* endpoints in integration. +#### **Scenario: User can upgrade multiple conflict-free prebuilt rules selected on the page** + +**Automation**: 1 e2e test with mock rules + integration tests with mock rules that would test /status and /upgrade/\* endpoints in integration. ```Gherkin -Given no prebuilt rules are installed in Kibana -And there are X prebuilt rules available to install -When user opens the Add Rules page -Then prebuilt rules available for installation should be displayed in the table -When user selects rules -Then user should see a CTA to install number of rules +Given X prebuilt rules are installed in Kibana +And for Y of the installed rules there are new versions available +And user opens the Rule Updates table +Then Y rules available for upgrade should be displayed in the table +When user selects Z (where Z < Y) rules, which have no upgrade conflicts +Then user should see a CTA to upgrade rules When user clicks the CTA -Then success message should be displayed after installation -And all the installed rules should be removed from the table -When user navigates back to the Rule Management page -Then user should see a CTA to install prebuilt rules -And user should see the number of rules available to install decreased by number of installed rules +Then success message should be displayed after upgrade +And all the upgraded rules should be removed from the table +And user should see the number of rules available to upgrade decreased by number of upgraded rules Examples: - | Y | + | Z | | a few rules on the page, e.g. 2 | | all rules on the page, e.g. 12 | ``` -#### **Scenario: User can install all available prebuilt rules at once** +#### **Scenario: User cannot upgrade selected prebuilt rules with conflicts** -**Automation**: 1 e2e test with mock rules + integration tests with mock rules that would test /status and /installation/\* endpoints in integration. +**Automation**: 1 e2e test with mock rules ```Gherkin -Given no prebuilt rules are installed in Kibana -And there are X prebuilt rules available to install -When user opens the Add Rules page -Then prebuilt rules available for installation should be displayed in the table -When user installs all rules -Then success message should be displayed after installation -And all the rules should be removed from the table -And user should see a message indicating that all available rules have been installed -And user should see a CTA that leads to the Rule Management page -When user clicks on the CTA -Then user should be navigated back to Rule Management page -And user should NOT see a CTA to install prebuilt rules -And user should NOT see a number of rules available to install -``` - -#### **Scenario: Empty screen is shown when all prebuilt rules are installed** - -**Automation**: 1 e2e test with mock rules + 1 integration test. +Given X prebuilt rules are installed in Kibana +And for Y of the installed rules there are new versions available +And all of those Y new versions have conflicts with the current versions +And user is on the Rule Management page +When user is on the Rule Updates table +When user selects rules, all of which have upgrade conflicts +Then user should see a CTA to upgrade number of rules, which should be disabled +When user hovers on the CTA to upgrade multiple rules +Then a message should be displayed that informs the user why the rules cannot be updated -```Gherkin -Given all the available prebuilt rules are installed in Kibana -When user opens the Add Rules page -Then user should see a message indicating that all available rules have been installed -And user should see a CTA that leads to the Rule Management page +Examples: + | Z | + | a few rules on the page, e.g. 2 | + | all rules on the page, e.g. 12 | ``` -#### **Scenario: User can preview rules available for installation** +#### **Scenario: User can upgrade all available conflict-free prebuilt rules at once** -**Automation**: 1 e2e test +**Automation**: 1 e2e test with mock rules + integration tests with mock rules that would test /status and /upgrade/\* endpoints in integration. ```Gherkin -Given no prebuilt rules are installed in Kibana -And there are 2 rules available to install -When user opens the Add Rules page -Then all rules available for installation should be displayed in the table -When user opens the rule preview for the 1st rule -Then the preview should open -When user closes the preview -Then it should disappear +Given X prebuilt rules are installed in Kibana +And for Y of the installed rules there are new versions available +And those Y new versions don't have conflicts with the current versions +When user is on the Rule Updates table +Then Y rules available for upgrade should be displayed in the table +When user upgrades all rules +Then success message should be displayed after upgrade +And user should NOT see a CTA to upgrade prebuilt rules +And user should NOT see a number of rules available to upgrade ``` -#### **Scenario: User can install a rule using the rule preview** +#### **Scenario: User cannot upgrade all prebuilt rules at once if they have upgrade conflicts** -**Automation**: 1 e2e test +**Automation**: 1 e2e test with mock rules ```Gherkin -Given no prebuilt rules are installed in Kibana -And there are 2 rules available to install -When user opens the Add Rules page -Then all rules available for installation should be displayed in the table -When user opens the rule preview for the rule -Then the preview should open -When user installs the rule using a CTA in the rule preview -Then the rule should be installed -And a success message should be displayed after installation -And the rule should be removed from the Add Rules table -When user navigates back to the Rule Management page -Then user should see a CTA to install prebuilt rules -And user should see the number of rules available to install as initial number minus 1 +Given X prebuilt rules are installed in Kibana +And for Y of the installed rules there are new versions available +And all Y new versions have conflicts with the current versions +When user opens the Rule Updates table +Then Y rules available for upgrade should be displayed in the table +Then user should see a CTA to upgrade all rules +And the CTA to upgrade all rules should be disabled +When user hovers on the CTA to upgrade all rules +Then a message should be displayed that informs the user why the rules cannot be updated ``` -#### **Scenario: User can see correct rule information in preview before installing** +#### **Scenario: User can upgrade only conflict-free rules when a mix of rules with and without conflicts are selected for upgrade** -**Automation**: 1 e2e test +**Automation**: 1 e2e test with mock rules ```Gherkin -Given no prebuilt rules are installed in Kibana -And there are X prebuilt rules of all types available to install -When user opens the Add Rules page -Then all X rules available for installation should be displayed in the table -When user opens a rule preview for any rule -Then the preview should appear -And all properties of a rule should be displayed in the correct tab and section of the preview (see examples of rule properties above) -``` - -#### **Scenario: Tabs and sections without content should be hidden in preview before installing** - -**Automation**: 1 e2e test +Given X prebuilt rules are installed in Kibana +And for Y of the installed rules there are new versions available +And a subset Z of the rules have conflicts with the current versions +And user is on the Rule Updates table +Then Y rules available for upgrade should be displayed in the table +And user selects rules, which is a mixture of rules with and without upgrade conflicts +Then user should see a CTA to upgrade number of rules, which is enabled +When user clicks the CTA +A modal window should inform the user that only W rules without conflicts will be upgraded +When user confirms the action in the modal +Then success message should be displayed after upgrade informing that W rules were updated +And the W upgraded rules should be removed from the table +And the remaining Z - W rules should still be present in the table +And user should see the number of rules available to upgrade decreased by W number of upgraded rules -```Gherkin -Given no prebuilt rules are installed in Kibana -And there is at least 1 rule available to install -And this rule has neither Setup guide nor Investigation guide -When user opens the Add Rules page -Then all rules available for installation should be displayed in the table -When user opens the rule preview for this rule -Then the preview should open -And the Setup Guide section should NOT be displayed in the Overview tab -And the Investigation Guide tab should NOT be displayed +Examples: + | Z | + | a few rules on the page, e.g. 2 | + | all rules on the page, e.g. 12 | ``` -### Rule installation workflow: filtering, sorting, pagination - -TODO: add scenarios https://github.com/elastic/kibana/issues/166215 - -### Rule installation workflow: misc cases - -#### **Scenario: User opening the Add Rules page sees a loading skeleton until the package installation is completed** +#### **Scenario: User can upgrade only conflict-free rules when attempting to upgrade all rules** -**Automation**: unit tests. +**Automation**: 1 e2e test with mock rules ```Gherkin -Given prebuilt rules package is not installed -When user opens the Add Rules page -Then user should see a loading skeleton until the package installation is completed +Given X prebuilt rules are installed in Kibana +And for Y of the installed rules there are new versions available +And Z (where Z < Y) rules have conflicts with the current versions +And user is on the Rule Updates table +Then Y rules available for upgrade should be displayed in the table +Then user should see an enabled CTA to upgrade all rules +When user clicks the CTA +A modal window should inform the user that only K (where K < Y) rules without conflicts will be upgraded +When user confirms the action in the modal +Then success message should be displayed after upgrade informing that K rules were updated +And the K upgraded rules should be removed from the table +And the remaining M = Y - K rules should still be present in the table +And user should see the number of rules available to upgrade decreased by K number of upgraded rules ``` -#### **Scenario: User can navigate from the Add Rules page to the Rule Management page via breadcrumbs** - -**Automation**: 1 e2e test. -```Gherkin -Given user is on the Add Rules page -When user navigates to the Rule Management page via breadcrumbs -Then the Rule Management page should be displayed -``` +### Rule upgrade workflow: upgrading rules with rule type change -### Rule upgrade workflow: base cases +#### **Scenario: User can upgrade rule with rule type change individually** -#### **Scenario: User can upgrade prebuilt rules one by one** - -**Automation**: 1 e2e test with mock rules + integration tests with mock rules that would test /status and /upgrade/\* endpoints in integration. +**Automation**: 1 e2e test with mock rules ```Gherkin -Given X prebuilt rules are installed in Kibana -And for Y of the installed rules there are new versions available -And user is on the Rule Management page +Given a prebuilt rule is installed in Kibana +And this rule has an update available that changes its rule type When user opens the Rule Updates table -Then Y rules available for upgrade should be displayed in the table -When user upgrades one individual rule without previewing it -Then success message should be displayed after upgrade -And the upgraded rule should be removed from the table -And user should see the number of rules available to upgrade decreased by 1 +Then this rule should be displayed in the table +And the Upgrade Rule button should be disabled +And the user should not be able to upgrade them directly from the table +And there should be a message/tooltip indicating why the rule cannot be upgraded directly ``` -#### **Scenario: User can upgrade multiple prebuilt rules selected on the page** +#### **Scenario: User can bulk upgrade selected rules with rule type changes** -**Automation**: 1 e2e test with mock rules + integration tests with mock rules that would test /status and /upgrade/\* endpoints in integration. + +**Automation**: 1 e2e test with mock rules ```Gherkin Given X prebuilt rules are installed in Kibana -And for Y of the installed rules there are new versions available -And user is on the Rule Management page +And Y of these rules have updates available that change their rule types When user opens the Rule Updates table -Then Y rules available for upgrade should be displayed in the table -When user selects rules -Then user should see a CTA to upgrade number of rules -When user clicks the CTA -Then success message should be displayed after upgrade -And all the upgraded rules should be removed from the table -And user should see the number of rules available to upgrade decreased by number of upgraded rules - -Examples: - | Z | - | a few rules on the page, e.g. 2 | - | all rules on the page, e.g. 12 | +Then Y rules should be displayed in the table +When user selects Z rules (where Z < Y) with rule type changes +The button to upgrade the Z selected rules should be disabled +And the user should not be able to upgrade them directly from the table +And there should be a message/tooltip indicating why the rule cannot be upgraded directly ``` -#### **Scenario: User can upgrade all available prebuilt rules at once** +#### **Scenario: User can bulk upgrade all rules with rule type changes** -**Automation**: 1 e2e test with mock rules + integration tests with mock rules that would test /status and /upgrade/\* endpoints in integration. +**Automation**: 1 e2e test with mock rules ```Gherkin Given X prebuilt rules are installed in Kibana -And for Y of the installed rules there are new versions available -And user is on the Rule Management page +And all X rules have updates available that change their rule types When user opens the Rule Updates table -Then Y rules available for upgrade should be displayed in the table -When user upgrades all rules -Then success message should be displayed after upgrade -And user should NOT see a CTA to upgrade prebuilt rules -And user should NOT see a number of rules available to upgrade -And user should NOT see the Rule Updates table +Then X rules should be displayed in the table +The button to upgrade all rules with should be disabled +And the user should not be able to upgrade them directly from the table +And there should be a message/tooltip indicating why the rule cannot be upgraded directly ``` +### Rule upgrade workflow: rule previews + #### **Scenario: User can preview rules available for upgrade** ```Gherkin @@ -807,7 +513,9 @@ And the Investigation Guide tab should NOT be displayed TODO: add scenarios https://github.com/elastic/kibana/issues/166215 -### Rule upgrade workflow: viewing rule changes in JSON diff view +### MILESTONE 2 (Legacy) - Rule upgrade workflow: viewing rule changes in JSON diff view + +> These flow were created for Milestone 2 of the Prebuilt Rules Customization epic, before users could customize prebuilt rules. This section should be deleted once Milestone 3 goes live. #### **Scenario: User can see changes in a side-by-side JSON diff view** @@ -953,7 +661,9 @@ When a user expands all hidden sections Then all properties of the rule should be sorted alphabetically ``` -### Rule upgrade workflow: viewing rule changes in per-field diff view +### MILESTONE 2 (Legacy) - Rule upgrade workflow: viewing rule changes in per-field diff view + +> These flow were created for Milestone 2 of the Prebuilt Rules Customization epic, before users could customize prebuilt rules. This section should be deleted once Milestone 3 goes live. #### **Scenario: User can see changes in a side-by-side per-field diff view** @@ -1091,7 +801,7 @@ Then user should NOT see the Rule Updates tab until the package installation is ### Error handling -#### **Scenario: Error is handled when any operation on prebuilt rules fails** +#### **Scenario: Error is handled when any upgrade operation on prebuilt rules fails** **Automation**: e2e test with mock rules @@ -1102,29 +812,92 @@ Then user should see an error message Examples: | operation | - | installing all | - | installing selected | - | installing individual | | upgrading all | | upgrading selected | | upgrading individual | ``` -### Authorization / RBAC -#### **Scenario: User with read privileges on Security Solution cannot install prebuilt rules** +### Rule upgrade via the Prebuilt rules API + +There's a legacy prebuilt rules API and a new one. Both should be tested against two types of the package: with and without historical rule versions. + +#### **Scenario: API can upgrade prebuilt rules that are outdated** -**Automation**: 1 e2e test with mock rules + 3 integration tests with mock rules for the status and installation endpoints. +**Automation**: 4 integration tests with mock rules. ```Gherkin -Given user with "Security: read" privileges on Security Solution -And no prebuilt rules are installed in Kibana -And there are prebuilt rules available to install -When user opens the Add Rules page -Then user should see prebuilt rules available to install -But user should not be able to install them +Given the package is installed +And the package contains N rules +When user installs all rules via install +And new X+1 version of a rule asset +And user gets prebuilt rules status via status +Then the endpoint should return 200 with +When user upgrades all rules via upgrade +Then the endpoint should return 200 with + +Examples: + | package_type | api | assets_update | status_response | upgrade_response | + | with historical versions | legacy | gets added | not_updated: 1 | installed: 0, updated: 1 | + | w/o historical versions | legacy | replaces X | not_updated: 1 | installed: 0, updated: 1 | + | with historical versions | new | gets added | to_upgrade: 1 | total: 1, succeeded: 1 | + | w/o historical versions | new | replaces X | to_upgrade: 1 | total: 1, succeeded: 1 | ``` +TODO: Check why for the legacy API Dmitrii has added 2 integration tests for `rule package with historical versions` instead of 1: + +- `should update outdated prebuilt rules when previous historical versions available` +- `should update outdated prebuilt rules when previous historical versions unavailable` + +(NOTE: the second scenario tests that, if a new version of a rule is released, it can upgrade the current instance of that rule even if the historical versions of that rule are no longer in the package) + +Notes: + +- Legacy API: + - install: `PUT /api/detection_engine/rules/prepackaged` + - upgrade: `PUT /api/detection_engine/rules/prepackaged` + - status: `GET /api/detection_engine/rules/prepackaged/_status` +- New API: + - install: `POST /internal/detection_engine/prebuilt_rules/installation/_perform` + - upgrade: `POST /internal/detection_engine/prebuilt_rules/upgrade/_perform` + - status: `GET /internal/detection_engine/prebuilt_rules/status` + +#### **Scenario: API does not upgrade prebuilt rules if they are up to date** + +**Automation**: 4 integration tests with mock rules. + +```Gherkin +Given the package is installed +And the package contains N rules +When user installs all rules via install +And user gets prebuilt rules status via status +Then the endpoint should return 200 with +When user calls install +Then the endpoint should return 200 with +When user calls upgrade +Then the endpoint should return 200 with + +Examples: + | package_type | api | status_response | install_response | upgrade_response | + | with historical versions | legacy | not_installed: 0, not_updated: 0 | installed: 0, updated: 0 | installed: 0, updated: 0 | + | w/o historical versions | legacy | not_installed: 0, not_updated: 0 | installed: 0, updated: 0 | installed: 0, updated: 0 | + | with historical versions | new | to_install: 0, to_upgrade: 0 | total: 0, succeeded: 0 | total: 0, succeeded: 0 | + | w/o historical versions | new | to_install: 0, to_upgrade: 0 | total: 0, succeeded: 0 | total: 0, succeeded: 0 | +``` + +Notes: + +- Legacy API: + - install: `PUT /api/detection_engine/rules/prepackaged` + - upgrade: `PUT /api/detection_engine/rules/prepackaged` + - status: `GET /api/detection_engine/rules/prepackaged/_status` +- New API: + - install: `POST /internal/detection_engine/prebuilt_rules/installation/_perform` + - upgrade: `POST /internal/detection_engine/prebuilt_rules/upgrade/_perform` + - status: `GET /internal/detection_engine/prebuilt_rules/status` + +### Authorization / RBAC + #### **Scenario: User with read privileges on Security Solution cannot upgrade prebuilt rules** **Automation**: 1 e2e test with mock rules + 3 integration tests with mock rules for the status and upgrade endpoints. @@ -1137,24 +910,4 @@ When user opens the Rule Management page And user opens the Rule Updates table Then user should see prebuilt rules available to upgrade But user should not be able to upgrade them -``` - -### Kibana upgrade - -#### **Scenario: User can use prebuilt rules after upgrading Kibana from version A to B** - -**Automation**: not automated, manual testing required. - -```Gherkin -Given user is upgrading Kibana from version to version -And the instance contains already installed prebuilt rules -When the upgrade is complete -Then user should be able to install new prebuilt rules -And delete installed prebuilt rules -And upgrade installed prebuilt rules that have newer versions in - -Examples: - | A | B | - | 8.7 | 8.9.0 | - | 7.17.x | 8.9.0 | -``` +``` \ No newline at end of file From 21008d2759e8d25b0b65b19936fabf8ffeaa1630 Mon Sep 17 00:00:00 2001 From: Robert Jaszczurek <92210485+rbrtj@users.noreply.github.com> Date: Thu, 19 Dec 2024 16:33:42 +0100 Subject: [PATCH 2/5] [ML] Data frame analytics: Updates Results Explorer flyout footer buttons alignment (#204735) Fix for: [#204601](https://github.com/elastic/kibana/issues/204601) After: Results explorer: image Analytics map: image --- .../analytics_id_selector.tsx | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/x-pack/platform/plugins/shared/ml/public/application/data_frame_analytics/pages/components/analytics_selector/analytics_id_selector.tsx b/x-pack/platform/plugins/shared/ml/public/application/data_frame_analytics/pages/components/analytics_selector/analytics_id_selector.tsx index 9fe4da68aa6f8..08360eb4f2cca 100644 --- a/x-pack/platform/plugins/shared/ml/public/application/data_frame_analytics/pages/components/analytics_selector/analytics_id_selector.tsx +++ b/x-pack/platform/plugins/shared/ml/public/application/data_frame_analytics/pages/components/analytics_selector/analytics_id_selector.tsx @@ -281,7 +281,18 @@ export function AnalyticsIdSelector({ {renderTabs()} - + + + + {i18n.translate('xpack.ml.analyticsSelector.closeFlyoutButton', { + defaultMessage: 'Close', + })} + + - - - {i18n.translate('xpack.ml.analyticsSelector.closeFlyoutButton', { - defaultMessage: 'Close', - })} - - From b50bec8f2399e50a7647872897b327fe5139c052 Mon Sep 17 00:00:00 2001 From: Robert Jaszczurek <92210485+rbrtj@users.noreply.github.com> Date: Thu, 19 Dec 2024 16:35:37 +0100 Subject: [PATCH 3/5] [ML] Data frame analytics: Adds missing space between lines in delete job modal (#204732) Fix for: [#204598](https://github.com/elastic/kibana/issues/204598) After: image --- .../action_delete/delete_action_modal.tsx | 27 ++++++++++++------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/x-pack/platform/plugins/shared/ml/public/application/data_frame_analytics/pages/analytics_management/components/action_delete/delete_action_modal.tsx b/x-pack/platform/plugins/shared/ml/public/application/data_frame_analytics/pages/analytics_management/components/action_delete/delete_action_modal.tsx index 4b17004865502..6b7569dcddd8d 100644 --- a/x-pack/platform/plugins/shared/ml/public/application/data_frame_analytics/pages/analytics_management/components/action_delete/delete_action_modal.tsx +++ b/x-pack/platform/plugins/shared/ml/public/application/data_frame_analytics/pages/analytics_management/components/action_delete/delete_action_modal.tsx @@ -14,6 +14,7 @@ import { EuiFlexGroup, EuiFlexItem, EUI_MODAL_CONFIRM_BUTTON, + EuiSpacer, } from '@elastic/eui'; import type { DeleteAction } from './use_delete_action'; @@ -79,16 +80,22 @@ export const DeleteActionModal: FC = ({ {userCanDeleteIndex && dataViewExists && ( - + <> + + + )} From 84fcda021be1d71018fa77005837da7e932c6d7f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alejandro=20Fern=C3=A1ndez=20Haro?= Date: Thu, 19 Dec 2024 16:55:02 +0100 Subject: [PATCH 4/5] [ES `body` removal] `@elastic/appex-sharedux` (#204874) ## Summary Attempt to remove the deprecated `body` in the ES client. --- .../es/content_stream/content_stream.test.ts | 2 +- .../adapters/es/content_stream/content_stream.ts | 2 +- .../blob_storage_service/adapters/es/mappings.ts | 5 +---- .../server/file_client/create_es_file_client.test.ts | 2 +- .../plugins/reporting/server/lib/store/store.test.ts | 12 ++++++------ x-pack/plugins/reporting/server/lib/store/store.ts | 2 +- .../reporting/server/lib/tasks/execute_report.ts | 2 +- 7 files changed, 12 insertions(+), 15 deletions(-) diff --git a/src/plugins/files/server/blob_storage_service/adapters/es/content_stream/content_stream.test.ts b/src/plugins/files/server/blob_storage_service/adapters/es/content_stream/content_stream.test.ts index 97ea43a4ad1d8..4e6c9542d9e3d 100644 --- a/src/plugins/files/server/blob_storage_service/adapters/es/content_stream/content_stream.test.ts +++ b/src/plugins/files/server/blob_storage_service/adapters/es/content_stream/content_stream.test.ts @@ -14,7 +14,7 @@ import { encode, decode } from '@kbn/cbor'; import { elasticsearchServiceMock, loggingSystemMock } from '@kbn/core/server/mocks'; import { ContentStream, ContentStreamEncoding, ContentStreamParameters } from './content_stream'; import type { GetResponse } from '@elastic/elasticsearch/lib/api/types'; -import * as estypes from '@elastic/elasticsearch/lib/api/typesWithBodyKey'; +import * as estypes from '@elastic/elasticsearch/lib/api/types'; import { FileDocument } from '../../../../file_client/file_metadata_client/adapters/es_index'; import { IndexRequest } from '@elastic/elasticsearch/lib/api/types'; diff --git a/src/plugins/files/server/blob_storage_service/adapters/es/content_stream/content_stream.ts b/src/plugins/files/server/blob_storage_service/adapters/es/content_stream/content_stream.ts index 1f2517feb4e43..2cda6188fc8b3 100644 --- a/src/plugins/files/server/blob_storage_service/adapters/es/content_stream/content_stream.ts +++ b/src/plugins/files/server/blob_storage_service/adapters/es/content_stream/content_stream.ts @@ -15,7 +15,7 @@ import { ByteSizeValue } from '@kbn/config-schema'; import { defaults } from 'lodash'; import { Duplex, Writable, Readable } from 'stream'; -import { GetResponse } from '@elastic/elasticsearch/lib/api/typesWithBodyKey'; +import { GetResponse } from '@elastic/elasticsearch/lib/api/types'; import { inspect } from 'util'; import { wrapErrorAndReThrow } from '../../../../file_client/utils'; import type { FileChunkDocument } from '../mappings'; diff --git a/src/plugins/files/server/blob_storage_service/adapters/es/mappings.ts b/src/plugins/files/server/blob_storage_service/adapters/es/mappings.ts index 179c8bcef5d8c..4f27ce44bba49 100644 --- a/src/plugins/files/server/blob_storage_service/adapters/es/mappings.ts +++ b/src/plugins/files/server/blob_storage_service/adapters/es/mappings.ts @@ -7,10 +7,7 @@ * License v3.0 only", or the "Server Side Public License, v 1". */ -import type { - MappingTypeMapping, - MappingProperty, -} from '@elastic/elasticsearch/lib/api/typesWithBodyKey'; +import type { MappingTypeMapping, MappingProperty } from '@elastic/elasticsearch/lib/api/types'; /** * These are the fields we expect to find a given document acting as a file chunk. diff --git a/src/plugins/files/server/file_client/create_es_file_client.test.ts b/src/plugins/files/server/file_client/create_es_file_client.test.ts index 2edc1fe2820d2..98f22801b0991 100644 --- a/src/plugins/files/server/file_client/create_es_file_client.test.ts +++ b/src/plugins/files/server/file_client/create_es_file_client.test.ts @@ -16,7 +16,7 @@ import { MockedLogger } from '@kbn/logging-mocks'; import { createEsFileClient } from './create_es_file_client'; import { FileClient } from './types'; import { ElasticsearchBlobStorageClient } from '../blob_storage_service'; -import * as estypes from '@elastic/elasticsearch/lib/api/typesWithBodyKey'; +import * as estypes from '@elastic/elasticsearch/lib/api/types'; import { FileDocument } from './file_metadata_client/adapters/es_index'; describe('When initializing file client via createESFileClient()', () => { diff --git a/x-pack/plugins/reporting/server/lib/store/store.test.ts b/x-pack/plugins/reporting/server/lib/store/store.test.ts index 5920e6a05eb29..3d5b5169d9c14 100644 --- a/x-pack/plugins/reporting/server/lib/store/store.test.ts +++ b/x-pack/plugins/reporting/server/lib/store/store.test.ts @@ -4,7 +4,7 @@ * 2.0; you may not use this file except in compliance with the Elastic License * 2.0. */ -import * as estypes from '@elastic/elasticsearch/lib/api/typesWithBodyKey'; +import * as estypes from '@elastic/elasticsearch/lib/api/types'; import { elasticsearchServiceMock, loggingSystemMock } from '@kbn/core/server/mocks'; import { JOB_STATUS } from '@kbn/reporting-common'; import { ReportDocument } from '@kbn/reporting-common/types'; @@ -212,7 +212,7 @@ describe('ReportingStore', () => { const [[updateCall]] = mockEsClient.update.mock.calls; - const response = (updateCall as estypes.UpdateRequest).body?.doc as Report; + const response = (updateCall as estypes.UpdateRequest)?.doc as Report; expect(response.migration_version).toBe(`7.14.0`); expect(response.status).toBe(`processing`); expect(updateCall.if_seq_no).toBe(42); @@ -242,7 +242,7 @@ describe('ReportingStore', () => { await store.setReportFailed(report, { errors: 'yes' } as any); const [[updateCall]] = mockEsClient.update.mock.calls; - const response = (updateCall as estypes.UpdateRequest).body?.doc as Report; + const response = (updateCall as estypes.UpdateRequest)?.doc as Report; expect(response.migration_version).toBe(`7.14.0`); expect(response.status).toBe(`failed`); expect(updateCall.if_seq_no).toBe(43); @@ -272,7 +272,7 @@ describe('ReportingStore', () => { await store.setReportError(report, { errors: 'yes' } as any); const [[updateCall]] = mockEsClient.update.mock.calls; - const response = (updateCall as estypes.UpdateRequest).body?.doc as Report; + const response = (updateCall as estypes.UpdateRequest)?.doc as Report; expect(response.migration_version).toBe(`7.14.0`); expect(updateCall.if_seq_no).toBe(43); expect(updateCall.if_primary_term).toBe(10002); @@ -301,7 +301,7 @@ describe('ReportingStore', () => { await store.setReportCompleted(report, { certainly_completed: 'yes' } as any); const [[updateCall]] = mockEsClient.update.mock.calls; - const response = (updateCall as estypes.UpdateRequest).body?.doc as Report; + const response = (updateCall as estypes.UpdateRequest)?.doc as Report; expect(response.migration_version).toBe(`7.14.0`); expect(response.status).toBe(`completed`); expect(updateCall.if_seq_no).toBe(44); @@ -336,7 +336,7 @@ describe('ReportingStore', () => { } as any); const [[updateCall]] = mockEsClient.update.mock.calls; - const response = (updateCall as estypes.UpdateRequest).body?.doc as Report; + const response = (updateCall as estypes.UpdateRequest)?.doc as Report; expect(response.migration_version).toBe(`7.14.0`); expect(response.status).toBe(`completed_with_warnings`); diff --git a/x-pack/plugins/reporting/server/lib/store/store.ts b/x-pack/plugins/reporting/server/lib/store/store.ts index 05b34f2c04533..85da045996279 100644 --- a/x-pack/plugins/reporting/server/lib/store/store.ts +++ b/x-pack/plugins/reporting/server/lib/store/store.ts @@ -86,7 +86,7 @@ const esDocForUpdate = ( if_seq_no: report._seq_no, if_primary_term: report._primary_term, refresh: 'wait_for' as estypes.Refresh, - body: { doc }, + doc, }; }; diff --git a/x-pack/plugins/reporting/server/lib/tasks/execute_report.ts b/x-pack/plugins/reporting/server/lib/tasks/execute_report.ts index 4ca908310c78c..80cbb1e71a5d3 100644 --- a/x-pack/plugins/reporting/server/lib/tasks/execute_report.ts +++ b/x-pack/plugins/reporting/server/lib/tasks/execute_report.ts @@ -12,7 +12,7 @@ import { Writable } from 'stream'; import { finished } from 'stream/promises'; import { setTimeout } from 'timers/promises'; -import { UpdateResponse } from '@elastic/elasticsearch/lib/api/typesWithBodyKey'; +import { UpdateResponse } from '@elastic/elasticsearch/lib/api/types'; import type { Logger } from '@kbn/core/server'; import { CancellationToken, From 5df5e4f0d004d0668c14d1177ff3a5b2bc7f65ca Mon Sep 17 00:00:00 2001 From: Nathan Reese Date: Thu, 19 Dec 2024 09:21:40 -0700 Subject: [PATCH 5/5] [visualizations] fix eslint error (#204972) https://github.com/elastic/kibana/pull/204816 merged into main then https://github.com/elastic/kibana/pull/204832 merged into main. The combination of these merges resulted in an eslint error in main. --- .../public/legacy/embeddable/visualize_embeddable.tsx | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/plugins/visualizations/public/legacy/embeddable/visualize_embeddable.tsx b/src/plugins/visualizations/public/legacy/embeddable/visualize_embeddable.tsx index e343fd535a85e..1f631f30f8eb5 100644 --- a/src/plugins/visualizations/public/legacy/embeddable/visualize_embeddable.tsx +++ b/src/plugins/visualizations/public/legacy/embeddable/visualize_embeddable.tsx @@ -22,11 +22,7 @@ import type { DataView } from '@kbn/data-views-plugin/public'; import { Warnings } from '@kbn/charts-plugin/public'; import { hasUnsupportedDownsampledAggregationFailure } from '@kbn/search-response-warnings'; import { Adapters } from '@kbn/inspector-plugin/public'; -import { - Embeddable, - EmbeddableInput, - EmbeddableOutput, -} from '@kbn/embeddable-plugin/public'; +import { Embeddable, EmbeddableInput, EmbeddableOutput } from '@kbn/embeddable-plugin/public'; import { SavedObjectEmbeddableInput } from '@kbn/embeddable-plugin/common'; import { ExpressionAstExpression,