Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Security Solution] Unable to upgrade rules with missing base version #200904

Closed
Tracked by #201502
xcrzx opened this issue Nov 20, 2024 · 4 comments · Fixed by #201301
Closed
Tracked by #201502

[Security Solution] Unable to upgrade rules with missing base version #200904

xcrzx opened this issue Nov 20, 2024 · 4 comments · Fixed by #201301
Assignees
Labels
8.17 candidate bug Fixes for quality problems that affect the customer experience Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules area impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. Team:Detection Rule Management Security Detection Rule Management Team Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. v8.16.2 v8.17.0 v8.18.0

Comments

@xcrzx
Copy link
Contributor

xcrzx commented Nov 20, 2024

Epic: #174168
Related to: #200286

Summary

When a rule has a missing base version, the update to the version field is treated as a conflict, which blocks the update flow.

Steps to Reproduce

  1. Open any field in the update UI for a rule that has no base version.
  2. Attempt to resolve all conflicts and update the rule.

Expected Result

Users should be able to resolve conflicts and update the rule successfully.

Actual Result

Rule update is not possible, even after resolving all conflicts, due to an "invisible" conflict in the version field:

Image

@xcrzx xcrzx added 8.18 candidate bug Fixes for quality problems that affect the customer experience Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules area impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Detection Rule Management Security Detection Rule Management Team Team:Detections and Resp Security Detection Response Team labels Nov 20, 2024
@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detections-response (Team:Detections and Resp)

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

@xcrzx xcrzx changed the title [Security Solution] Version updates considered conflicts during rule update [Security Solution] Unable to upgrade rules with missing base version Nov 20, 2024
@maximpn maximpn self-assigned this Nov 21, 2024
kibanamachine pushed a commit to kibanamachine/kibana that referenced this issue Nov 25, 2024
…ules with missing base version (elastic#201301)

**Resolves: elastic#200904

## Summary

This PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.

## Details

Each Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.

A generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.

The fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.

(cherry picked from commit dea9312)
kibanamachine pushed a commit to kibanamachine/kibana that referenced this issue Nov 25, 2024
…ules with missing base version (elastic#201301)

**Resolves: elastic#200904

## Summary

This PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.

## Details

Each Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.

A generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.

The fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.

(cherry picked from commit dea9312)
kibanamachine pushed a commit to kibanamachine/kibana that referenced this issue Nov 25, 2024
…ules with missing base version (elastic#201301)

**Resolves: elastic#200904

## Summary

This PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.

## Details

Each Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.

A generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.

The fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.

(cherry picked from commit dea9312)
@maximpn
Copy link
Contributor

maximpn commented Nov 26, 2024

The fix was implemented in #201301 and backported to 8.x in #201657, to 8.17 in #201656 and to 8.16 in #201655.

paulinashakirova pushed a commit to paulinashakirova/kibana that referenced this issue Nov 26, 2024
…ules with missing base version (elastic#201301)

**Resolves: elastic#200904

## Summary

This PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.

## Details

Each Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.

A generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.

The fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.
CAWilson94 pushed a commit to CAWilson94/kibana that referenced this issue Dec 12, 2024
…ules with missing base version (elastic#201301)

**Resolves: elastic#200904

## Summary

This PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.

## Details

Each Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.

A generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.

The fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
8.17 candidate bug Fixes for quality problems that affect the customer experience Feature:Prebuilt Detection Rules Security Solution Prebuilt Detection Rules area impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. Team:Detection Rule Management Security Detection Rule Management Team Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. v8.16.2 v8.17.0 v8.18.0
Projects
None yet
4 participants