-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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] Enable prebuilt rules customization feature flag #212761
base: main
Are you sure you want to change the base?
[Security Solution] Enable prebuilt rules customization feature flag #212761
Conversation
100afa4
to
86db5ac
Compare
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
Pinging @elastic/security-solution (Team: SecuritySolution) |
Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ftr_configs.yml LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maximpn Thank you, I guess that was quite an effort.
Overall LGTM, but I'm not sure I understand the approach with removing the FF checks from the code but keeping the FF itself. I'd suggest we remove the FF from x-pack/solutions/security/plugins/security_solution/common/experimental_features.ts
as well to make sure there's no leftover logic that depends on it.
I left some comments but I don't think any of them are critical. Will be happy to approve the PR when you respond to them.
* Turned: 12 March 2025 in https://github.com/elastic/kibana/pull/212761 | ||
* | ||
* Enabling the FF required fixing some tests. | ||
* To disable revert merge commit by https://github.com/elastic/kibana/pull/212761. | ||
*/ | ||
prebuiltRulesCustomizationEnabled: false, | ||
prebuiltRulesCustomizationEnabled: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we say that in order to disable the feature back we have to revert the commit instead of just flipping the feature flag to false
, why are we keeping the feature flag in the codebase? Can we remove it right away in this PR?
IMHO keeping it in the code overcomplicates the setup. There's a FF, but it's not respected anymore, according to the PR description: "FF logic was removed from the codebase". Or is it? One has to check the code to be sure. This could be confusing for future us or someone else who'd find this flag.
// We show the upselling message only if the feature flag is enabled | ||
const isFeatureFlagEnabled = useIsExperimentalFeatureEnabled('prebuiltRulesCustomizationEnabled'); | ||
return isFeatureFlagEnabled ? upsellingMessage : undefined; | ||
return useUpsellingMessage(messageId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const isRulesCustomizationEnabled = !upsellingMessage; | ||
const customizationDisabledReason = isRulesCustomizationEnabled | ||
? undefined | ||
: PrebuiltRulesCustomizationDisabledReason.License; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...ution/public/detections/components/rules/related_integrations/integrations_popover/index.tsx
Show resolved
Hide resolved
const prebuiltRule = getRuleMock( | ||
getQueryRuleParams({ | ||
ruleId: 'rule-1', | ||
immutable: true, | ||
ruleSource: { | ||
type: 'external', | ||
isCustomized: false, | ||
}, | ||
}) | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Maybe we could specify a mixture of non-customized, customized, and even custom rules here. Or have separate unit tests for these cases.
Nit because the main tests for this should be at the integration level.
@@ -53,7 +53,7 @@ describe('DetectionRulesClient.createCustomRule', () => { | |||
mlAuthz, | |||
savedObjectsClient, | |||
license: licenseMock.createLicenseMock(), | |||
experimentalFeatures: { prebuiltRulesCustomizationEnabled: true } as ExperimentalFeatures, | |||
experimentalFeatures: {} as ExperimentalFeatures, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Detection rules client doesn't depend on experimentalFeatures
anymore, so this could be removed completely if we remove the experimentalFeatures
parameter from the createDetectionRulesClient
function.
@@ -1525,7 +1525,7 @@ export default ({ getService }: FtrProviderContext): void => { | |||
}, | |||
]; | |||
cases.forEach(({ type, value }) => { | |||
it(`should return error when trying to apply "${type}" edit action to prebuilt rule`, async () => { | |||
it(`should NOT return error when trying to apply "${type}" edit action to prebuilt rule`, async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this test should be moved outside of this file and be split into two tests:
- The first one would be created in
x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/prebuilt_rule_customization/customization_disabled/customization_via_bulk_editing.ts
and would test that itshould return error when trying to apply "${type}" edit action to prebuilt rule
. - The second one would be created in
x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/prebuilt_rule_customization/customization_enabled/customization_via_bulk_editing.ts
and would test that itshould NOT return error when trying to apply "${type}" edit action to prebuilt rule
.
|
||
// if rule action is applied together with another edit action, that can't be applied to prebuilt rule (for example: tags action) | ||
// bulk edit request should return error | ||
it(`should return error if one of edit action is not eligible for prebuilt rule`, async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly, this should go to x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/prebuilt_rule_customization/customization_disabled/customization_via_bulk_editing.ts
.
@@ -201,47 +201,29 @@ export default ({ getService }: FtrProviderContext): void => { | |||
expect(ruleBody.tags).toEqual(tags); | |||
}); | |||
|
|||
it('should validate immutable rule edit', async () => { | |||
it('should allow prebuilt rules edit', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly, this should be moved to x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/prebuilt_rule_customization/customization_enabled/customization_via_bulk_editing.ts
.
@@ -1625,7 +1625,7 @@ export default ({ getService }: FtrProviderContext): void => { | |||
|
|||
describe('supporting prebuilt rule customization', () => { | |||
describe('compatibility with prebuilt rule fields', () => { | |||
it('rejects rules with "immutable: true" when the feature flag is disabled', async () => { | |||
it('accepts rules with "immutable: true"', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole describe('supporting prebuilt rule customization'
should be moved under x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/prebuilt_rule_customization/customization_enabled
.
86db5ac
to
be648a4
Compare
be648a4
to
afd314e
Compare
/ci |
💔 Build Failed
Failed CI Steps
Test Failures
Metrics [docs]Async chunks
Page load bundle
Unknown metric groupsESLint disabled line counts
Total ESLint disabled count
History
cc @maximpn |
Addresses: #180267
Summary
This PR enables
prebuiltRulesCustomizationEnabled
feature flag.Details
Besides simply enabling
prebuiltRulesCustomizationEnabled
feature flag the following required changes were done