From 765624fb237be9f600bd6c0e1d9548836ee777b1 Mon Sep 17 00:00:00 2001 From: Davis Plumlee Date: Wed, 29 May 2024 17:50:13 -0400 Subject: [PATCH 1/6] adds initial cases --- .../installation_and_upgrade.md | 60 +++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md b/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md index beda8a9517830..adf3d004e161d 100644 --- a/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md +++ b/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md @@ -55,6 +55,7 @@ Status: `in progress`. The current test plan matches `Milestone 2` of the [Rule - [**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: diff algorithms](#rule-upgrade-workflow-diff-algorithms) - [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) @@ -815,6 +816,65 @@ And the Investigation Guide tab should NOT be displayed TODO: add scenarios https://github.com/elastic/kibana/issues/166215 +### Rule upgrade workflow: diff algorithms + +#### **Scenario: Simple diff algorithm AAA** + +**Automation** 1 integration test + +```Gherkin +Given at least 1 prebuilt rule is installed in Kibana +And for this rule there is a new version available +And this rule has an existing base version for +And the current version of is identical to the base version +And the target version of is identical to the base version +Then the diff algorithm should return with no update +And there should be no conflict + +Examples: +| field | +| name | +| risk_score| +``` + +#### **Scenario: Simple diff algorithm ABA** + +**Automation** 1 integration test + +```Gherkin +Given at least 1 prebuilt rule is installed in Kibana +And for this rule there is a new version available +And this rule has an existing base version for +And the current version of is different from the base version +And the target version of is identical to the base version +Then the diff algorithm should return the current version of +And there should be no conflict + +Examples: +| field | +| name | +| risk_score| +``` + +#### **Scenario: Simple diff algorithm AAB** + +**Automation** 1 integration test + +```Gherkin +Given at least 1 prebuilt rule is installed in Kibana +And for this rule there is a new version available +And this rule has an existing base version for +And the current version of is identical to the base version +And the target version of is different from the base version +Then the diff algorithm should return the target version of +And there should be no conflict + +Examples: +| field | +| name | +| risk_score| +``` + ### Rule upgrade workflow: viewing rule changes in JSON diff view #### **Scenario: User can see changes in a side-by-side JSON diff view** From 4a2b9df31e896e1cdc4d7fd868ae20439dc21e17 Mon Sep 17 00:00:00 2001 From: Davis Plumlee Date: Wed, 29 May 2024 22:43:23 -0400 Subject: [PATCH 2/6] initial test plan --- .../installation_and_upgrade.md | 83 +++++++++++++++---- 1 file changed, 66 insertions(+), 17 deletions(-) diff --git a/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md b/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md index adf3d004e161d..4195b88390bcf 100644 --- a/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md +++ b/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md @@ -55,7 +55,12 @@ Status: `in progress`. The current test plan matches `Milestone 2` of the [Rule - [**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: diff algorithms](#rule-upgrade-workflow-diff-algorithms) + - [Rule upgrade workflow: simple diff algorithm](#rule-upgrade-workflow-simple-diff-algorithm) + - [**Scenario: Rule field doesn't have an update and has no custom value**](#scenario-rule-field-doesnt-have-an-update-and-has-no-custom-value) + - [**Scenario: Rule field doesn't have an update but has a custom value**](#scenario-rule-field-doesnt-have-an-update-but-has-a-custom-value) + - [**Scenario: Rule field has an update and doesn't have a custom value**](#scenario-rule-field-has-an-update-and-doesnt-have-a-custom-value) + - [**Scenario: Rule field has an update and a custom value that are the same**](#scenario-rule-field-has-an-update-and-a-custom-value-that-are-the-same) + - [**Scenario: Rule field has an update and a custom value that are NOT the same**](#scenario-rule-field-has-an-update-and-a-custom-value-that-are-not-the-same) - [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) @@ -816,19 +821,19 @@ And the Investigation Guide tab should NOT be displayed TODO: add scenarios https://github.com/elastic/kibana/issues/166215 -### Rule upgrade workflow: diff algorithms +### Rule upgrade workflow: simple diff algorithm -#### **Scenario: Simple diff algorithm AAA** +#### **Scenario: Rule field doesn't have an update and has no custom value** **Automation** 1 integration test ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And this rule has an existing base version for -And the current version of is identical to the base version -And the target version of is identical to the base version -Then the diff algorithm should return with no update +And this rule has an existing base version +And the current version of is unchanged from the base version +And there is no update for in this upgrade +Then the merged output should be the current verison of And there should be no conflict Examples: @@ -837,17 +842,17 @@ Examples: | risk_score| ``` -#### **Scenario: Simple diff algorithm ABA** +#### **Scenario: Rule field doesn't have an update but has a custom value** **Automation** 1 integration test ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And this rule has an existing base version for -And the current version of is different from the base version -And the target version of is identical to the base version -Then the diff algorithm should return the current version of +And this rule has an existing base version +And the current version of has changed from the base version +And there is no update for in this upgrade +Then the merged output should be the current verison of And there should be no conflict Examples: @@ -856,17 +861,17 @@ Examples: | risk_score| ``` -#### **Scenario: Simple diff algorithm AAB** +#### **Scenario: Rule field has an update and doesn't have a custom value** **Automation** 1 integration test ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And this rule has an existing base version for -And the current version of is identical to the base version -And the target version of is different from the base version -Then the diff algorithm should return the target version of +And this rule has an existing base version +And the current version of is unchanged from the base version +And there is a update for in this upgrade +Then the merged output should be the target verison of And there should be no conflict Examples: @@ -875,6 +880,50 @@ Examples: | risk_score| ``` +#### **Scenario: Rule field has an update and a custom value that are the same** + +**Automation** 1 integration test + +```Gherkin +Given at least 1 prebuilt rule is installed in Kibana +And for this rule there is a new version available +And this rule has an existing base version +And the current version of has changed from the base version +And there is a update for in this upgrade +And the current version and the update have the same value +Then the merged output should be the current verison of +And there should be no conflict + +CASE: should work the same if rule does not have an existing base version + +Examples: +| field | +| name | +| risk_score| +``` + +#### **Scenario: Rule field has an update and a custom value that are NOT the same** + +**Automation** 1 integration test + +```Gherkin +Given at least 1 prebuilt rule is installed in Kibana +And for this rule there is a new version available +And this rule has an existing base version +And the current version of has changed from the base version +And there is a update for in this upgrade +And the current version and the update do not have the same value +Then the merged output should be the current verison of +And there should be a conflict + +CASE: should return target version if rule does not have an existing base version + +Examples: +| field | +| name | +| risk_score| +``` + ### Rule upgrade workflow: viewing rule changes in JSON diff view #### **Scenario: User can see changes in a side-by-side JSON diff view** From 48f1a42cfeb4a5259d861d7fc0f60cbca33a3475 Mon Sep 17 00:00:00 2001 From: Davis Plumlee Date: Thu, 30 May 2024 12:13:34 -0400 Subject: [PATCH 3/6] adds more specific examples --- .../installation_and_upgrade.md | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md b/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md index 4195b88390bcf..53abe4bf07dd6 100644 --- a/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md +++ b/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md @@ -837,9 +837,9 @@ Then the merged output should be the current verison of And there should be no conflict Examples: -| field | -| name | -| risk_score| +| field | base_version | current_version | target_version | +| name | "A" | "A" | "A" | +| risk_score | 1 | 1 | 1 | ``` #### **Scenario: Rule field doesn't have an update but has a custom value** @@ -856,9 +856,9 @@ Then the merged output should be the current verison of And there should be no conflict Examples: -| field | -| name | -| risk_score| +| field | base_version | current_version | target_version | +| name | "A" | "B" | "A" | +| risk_score | 1 | 2 | 1 | ``` #### **Scenario: Rule field has an update and doesn't have a custom value** @@ -875,9 +875,9 @@ Then the merged output should be the target verison of And there should be no conflict Examples: -| field | -| name | -| risk_score| +| field | base_version | current_version | target_version | +| name | "A" | "A" | "B" | +| risk_score | 1 | 1 | 2 | ``` #### **Scenario: Rule field has an update and a custom value that are the same** @@ -897,9 +897,9 @@ And there should be no conflict CASE: should work the same if rule does not have an existing base version Examples: -| field | -| name | -| risk_score| +| field | base_version | current_version | target_version | +| name | "A" | "B" | "B" | +| risk_score | 1 | 2 | 2 | ``` #### **Scenario: Rule field has an update and a custom value that are NOT the same** @@ -919,9 +919,9 @@ And there should be a conflict CASE: should return target version if rule does not have an existing base version Examples: -| field | -| name | -| risk_score| +| field | base_version | current_version | target_version | +| name | "A" | "B" | "C" | +| risk_score | 1 | 2 | 3 | ``` ### Rule upgrade workflow: viewing rule changes in JSON diff view From 5dfb07b93b7d1d6bae6aeaa2a44ebeaedaf8fec0 Mon Sep 17 00:00:00 2001 From: Davis Plumlee Date: Fri, 31 May 2024 10:21:45 -0500 Subject: [PATCH 4/6] addresses comments --- .../installation_and_upgrade.md | 39 ++++++++++++------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md b/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md index 53abe4bf07dd6..ec92c4d46e3e9 100644 --- a/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md +++ b/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md @@ -830,10 +830,9 @@ TODO: add scenarios https://github.com/elastic/kibana/issues/166215 ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And this rule has an existing base version And the current version of is unchanged from the base version And there is no update for in this upgrade -Then the merged output should be the current verison of +Then the merged output should be the current version of And there should be no conflict Examples: @@ -849,10 +848,9 @@ Examples: ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And this rule has an existing base version And the current version of has changed from the base version And there is no update for in this upgrade -Then the merged output should be the current verison of +Then the merged output should be the current version of And there should be no conflict Examples: @@ -868,10 +866,9 @@ Examples: ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And this rule has an existing base version And the current version of is unchanged from the base version And there is a update for in this upgrade -Then the merged output should be the target verison of +Then the merged output should be the target version of And there should be no conflict Examples: @@ -887,14 +884,13 @@ Examples: ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And this rule has an existing base version And the current version of has changed from the base version And there is a update for in this upgrade And the current version and the update have the same value -Then the merged output should be the current verison of +Then the merged output should be the current version of And there should be no conflict -CASE: should work the same if rule does not have an existing base version +CASE: should work the same if rule's base version exists or not Examples: | field | base_version | current_version | target_version | @@ -909,21 +905,38 @@ Examples: ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And this rule has an existing base version And the current version of has changed from the base version And there is a update for in this upgrade And the current version and the update do not have the same value -Then the merged output should be the current verison of +Then the merged output should be the current version of And there should be a conflict -CASE: should return target version if rule does not have an existing base version - Examples: | field | base_version | current_version | target_version | | name | "A" | "B" | "C" | | risk_score | 1 | 2 | 3 | ``` +#### **Scenario: Rule field has an update and a custom value that are NOT the same and the rule base version doesn't exist** + +**Automation** 1 integration test + +```Gherkin +Given at least 1 prebuilt rule is installed in Kibana +And for this rule there is a new version available +And the base version of the rule cannot be determined +And the current version of has changed from the base version +And there is a update for in this upgrade +And the current version and the update do not have the same value +Then the merged output should be the target version of +And there should be a conflict + +Examples: +| field | base_version | current_version | target_version | +| name | N/A | "B" | "C" | +| risk_score | N/A | 2 | 3 | +``` + ### Rule upgrade workflow: viewing rule changes in JSON diff view #### **Scenario: User can see changes in a side-by-side JSON diff view** From 6fd0820d14bc815dc17178fa55e6fbc885cf88e0 Mon Sep 17 00:00:00 2001 From: Davis Plumlee Date: Tue, 4 Jun 2024 14:25:08 -0500 Subject: [PATCH 5/6] addresses comments --- .../installation_and_upgrade.md | 103 +++++++++++------- 1 file changed, 62 insertions(+), 41 deletions(-) diff --git a/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md b/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md index ec92c4d46e3e9..2212c4c0417d9 100644 --- a/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md +++ b/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md @@ -825,118 +825,139 @@ TODO: add scenarios https://github.com/elastic/kibana/issues/166215 #### **Scenario: Rule field doesn't have an update and has no custom value** -**Automation** 1 integration test +**Automation**: 2 integration tests with mock rules + a set of unit tests for the algorithm ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And the current version of is unchanged from the base version -And there is no update for in this upgrade -Then the merged output should be the current version of -And there should be no conflict +And field is not customized by the user (current version == base version) +And field is not updated by Elastic in this upgrade (target version == base version) +Then for field the diff algorithm should output the current version as the merged one without a conflict +And field should not be returned from the `upgrade/_review` API endpoint +And field should not be shown in the upgrade preview UI Examples: -| field | base_version | current_version | target_version | +| field_name | base_version | current_version | target_version | | name | "A" | "A" | "A" | | risk_score | 1 | 1 | 1 | ``` #### **Scenario: Rule field doesn't have an update but has a custom value** -**Automation** 1 integration test +**Automation**: 2 integration tests with mock rules + a set of unit tests for the algorithm ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And the current version of has changed from the base version -And there is no update for in this upgrade -Then the merged output should be the current version of -And there should be no conflict +And field is customized by the user (current version != base version) +And field is not updated by Elastic in this upgrade (target version == base version) +Then for field the diff algorithm should output the current version as the merged one without a conflict +And field should not be returned from the `upgrade/_review` API endpoint +And field should not be shown in the upgrade preview UI Examples: -| field | base_version | current_version | target_version | +| field_name | base_version | current_version | target_version | | name | "A" | "B" | "A" | | risk_score | 1 | 2 | 1 | ``` #### **Scenario: Rule field has an update and doesn't have a custom value** -**Automation** 1 integration test +**Automation**: 2 integration tests with mock rules + a set of unit tests for the algorithm ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And the current version of is unchanged from the base version -And there is a update for in this upgrade -Then the merged output should be the target version of -And there should be no conflict +And field is customized by the user (current version == base version) +And field is not updated by Elastic in this upgrade (target version != base version) +Then for field the diff algorithm should output the target version as the merged one without a conflict +And field should be returned from the `upgrade/_review` API endpoint +And field should be shown in the upgrade preview UI Examples: -| field | base_version | current_version | target_version | +| field_name | base_version | current_version | target_version | | name | "A" | "A" | "B" | | risk_score | 1 | 1 | 2 | ``` #### **Scenario: Rule field has an update and a custom value that are the same** -**Automation** 1 integration test +**Automation**: 2 integration tests with mock rules + a set of unit tests for the algorithm ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And the current version of has changed from the base version -And there is a update for in this upgrade -And the current version and the update have the same value -Then the merged output should be the current version of -And there should be no conflict - -CASE: should work the same if rule's base version exists or not +And field is customized by the user (current version != base version) +And field is updated by Elastic in this upgrade (target version != base version) +And customized field is the same as the Elastic update in this upgrade (current version == target version) +Then for field the diff algorithm should output the current version as the merged one without a conflict +And field should not be returned from the `upgrade/_review` API endpoint +And field should not be shown in the upgrade preview UI Examples: -| field | base_version | current_version | target_version | +| field_name | base_version | current_version | target_version | | name | "A" | "B" | "B" | | risk_score | 1 | 2 | 2 | ``` #### **Scenario: Rule field has an update and a custom value that are NOT the same** -**Automation** 1 integration test +**Automation**: 2 integration tests with mock rules + a set of unit tests for the algorithm ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And the current version of has changed from the base version -And there is a update for in this upgrade -And the current version and the update do not have the same value -Then the merged output should be the current version of -And there should be a conflict +And field is customized by the user (current version != base version) +And field is not updated by Elastic in this upgrade (target version != base version) +And customized field is different than the Elastic update in this upgrade (current version != target version) +Then for field the diff algorithm should output the current version as the merged one with a conflict +And field should be returned from the `upgrade/_review` API endpoint +And field should be shown in the upgrade preview UI Examples: -| field | base_version | current_version | target_version | +| field_name | base_version | current_version | target_version | | name | "A" | "B" | "C" | | risk_score | 1 | 2 | 3 | ``` #### **Scenario: Rule field has an update and a custom value that are NOT the same and the rule base version doesn't exist** -**Automation** 1 integration test +**Automation**: 2 integration tests with mock rules + a set of unit tests for the algorithm ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available And the base version of the rule cannot be determined -And the current version of has changed from the base version -And there is a update for in this upgrade -And the current version and the update do not have the same value -Then the merged output should be the target version of -And there should be a conflict +And customized field is different than the Elastic update in this upgrade (current version != target version) +Then for field the diff algorithm should output the target version as the merged one with a conflict +And field should be returned from the `upgrade/_review` API endpoint +And field should be shown in the upgrade preview UI Examples: -| field | base_version | current_version | target_version | +| field_name | base_version | current_version | target_version | | name | N/A | "B" | "C" | | risk_score | N/A | 2 | 3 | ``` +#### **Scenario: Rule field has an update and a custom value that are the same and the rule base version doesn't exist** + +**Automation**: 2 integration tests with mock rules + a set of unit tests for the algorithm + +```Gherkin +Given at least 1 prebuilt rule is installed in Kibana +And for this rule there is a new version available +And customized field is the same as the Elastic update in this upgrade (current version == target version) +Then for field the diff algorithm should output the current version as the merged one without a conflict +And field should not be returned from the `upgrade/_review` API endpoint +And field should not be shown in the upgrade preview UI + + +Examples: +| field_name | base_version | current_version | target_version | +| name | N/A | "A" | "A" | +| risk_score | N/A | 1 | 1 | +``` + ### Rule upgrade workflow: viewing rule changes in JSON diff view #### **Scenario: User can see changes in a side-by-side JSON diff view** From 4c9137f4e3db948af1eee87cfab5752d4d33158d Mon Sep 17 00:00:00 2001 From: Davis Plumlee Date: Fri, 7 Jun 2024 13:10:41 -0400 Subject: [PATCH 6/6] addresses comments --- .../prebuilt_rules/installation_and_upgrade.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md b/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md index 2212c4c0417d9..e6454eb424141 100644 --- a/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md +++ b/x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md @@ -61,6 +61,8 @@ Status: `in progress`. The current test plan matches `Milestone 2` of the [Rule - [**Scenario: Rule field has an update and doesn't have a custom value**](#scenario-rule-field-has-an-update-and-doesnt-have-a-custom-value) - [**Scenario: Rule field has an update and a custom value that are the same**](#scenario-rule-field-has-an-update-and-a-custom-value-that-are-the-same) - [**Scenario: Rule field has an update and a custom value that are NOT the same**](#scenario-rule-field-has-an-update-and-a-custom-value-that-are-not-the-same) + - [**Scenario: Rule field has an update and a custom value that are NOT the same and the rule base version doesn't exist**](#scenario-rule-field-has-an-update-and-a-custom-value-that-are-not-the-same-and-the-rule-base-version-doesnt-exist) + - [**Scenario: Rule field has an update and a custom value that are the same and the rule base version doesn't exist**](#scenario-rule-field-has-an-update-and-a-custom-value-that-are-the-same-and-the-rule-base-version-doesnt-exist) - [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) @@ -852,8 +854,8 @@ And for this rule there is a new version available And field is customized by the user (current version != base version) And field is not updated by Elastic in this upgrade (target version == base version) Then for field the diff algorithm should output the current version as the merged one without a conflict -And field should not be returned from the `upgrade/_review` API endpoint -And field should not be shown in the upgrade preview UI +And field should be returned from the `upgrade/_review` API endpoint +And field should be shown in the upgrade preview UI Examples: | field_name | base_version | current_version | target_version | @@ -868,8 +870,8 @@ Examples: ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available -And field is customized by the user (current version == base version) -And field is not updated by Elastic in this upgrade (target version != base version) +And field is not customized by the user (current version == base version) +And field is updated by Elastic in this upgrade (target version != base version) Then for field the diff algorithm should output the target version as the merged one without a conflict And field should be returned from the `upgrade/_review` API endpoint And field should be shown in the upgrade preview UI @@ -908,7 +910,7 @@ Examples: Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available And field is customized by the user (current version != base version) -And field is not updated by Elastic in this upgrade (target version != base version) +And field is updated by Elastic in this upgrade (target version != base version) And customized field is different than the Elastic update in this upgrade (current version != target version) Then for field the diff algorithm should output the current version as the merged one with a conflict And field should be returned from the `upgrade/_review` API endpoint @@ -946,6 +948,7 @@ Examples: ```Gherkin Given at least 1 prebuilt rule is installed in Kibana And for this rule there is a new version available +And the base version of the rule cannot be determined And customized field is the same as the Elastic update in this upgrade (current version == target version) Then for field the diff algorithm should output the current version as the merged one without a conflict And field should not be returned from the `upgrade/_review` API endpoint