-
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
[Cases] Adding feature flag for sub cases #95122
[Cases] Adding feature flag for sub cases #95122
Conversation
.github/CODEOWNERS
Outdated
@@ -339,6 +339,7 @@ | |||
# Security Solution sub teams | |||
/x-pack/plugins/case @elastic/security-threat-hunting | |||
/x-pack/test/case_api_integration @elastic/security-threat-hunting | |||
/x-pack/test/case_api_no_sub_cases_integration @elastic/security-threat-hunting |
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.
Once the sub cases feature is released we can delete these tests
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.
Is there any issue where we track what we should remove/enable when the sub cases feature is released?
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.
Good idea, I added it as an item here: #94115
@@ -171,7 +171,7 @@ export const ML_GROUP_IDS = [ML_GROUP_ID, LEGACY_ML_GROUP_ID]; | |||
/* | |||
Rule notifications options | |||
*/ | |||
export const ENABLE_CASE_CONNECTOR = true; | |||
export const ENABLE_CASE_CONNECTOR = 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.
@XavierM is there a better way to do this? could we tile this value to the subCasesEnabled
feature flag?
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 so we do not need to have two flags for the same thing, SUB_CASES_ENABLED
or CASE_CONNECTOR_ENABLED
should be sufficient.
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.
Hmm I think we might need two flags because the sub cases feature flag is stored in the config.ts
and is passed into the case api integration tests. I don't think we can use that value in the security solution right? The flag needs to exist in both cases and security solution right?
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 moved this flag to the cases plugin so we only have one flag now 👍
Pinging @elastic/security-threat-hunting (Team:Threat Hunting) |
@@ -86,6 +86,9 @@ async function executor( | |||
userActionService, | |||
alertsService, | |||
logger, | |||
// sub-cases-enabled: force this to true because we should never be able to call execute if the feature is disabled in the first | |||
// place. The plugin won't register case as a connector if subCasesEnabled is false. | |||
subCasesEnabled: 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.
As a precaution measure maybe we should throw an error if subCasesEnabled: true
so we don't allow the execution of the connector at all.
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.
Good idea, I added it.
}: RouteDeps) { | ||
const querySchema = subCasesEnabled |
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.
Do we document this API? If yes, then conditional params will be difficult to documented it. Why don't we leave the schema as it is but do not take into account the subCaseId at all and throw an error.
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 was thinking the same way, can we just have a global const for now
}: RouteDeps) { | ||
const querySchema = subCasesEnabled |
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.
FindQueryParamsRt.decode(request.query), | ||
fold(throwErrors(Boom.badRequest), identity) | ||
); | ||
const query = { |
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 is best to leave the schema as it was and just const subCaseId = subCasesEnabled ? query.subCaseId : undefined
and then relay on this variable for all check afterwards.
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 throw if the query parameter is defined now.
@@ -14,20 +14,25 @@ import { flattenCommentSavedObjects, wrapError } from '../../utils'; | |||
import { CASE_COMMENTS_URL } from '../../../../../common/constants'; | |||
import { defaultSortField } from '../../../../common'; | |||
|
|||
export function initGetAllCommentsApi({ caseService, router, logger }: RouteDeps) { | |||
export function initGetAllCommentsApi({ caseService, router, logger, subCasesEnabled }: RouteDeps) { | |||
const querySchema = subCasesEnabled |
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.
It seems that this pattern is being applied in our routes. Why we need to remove the subCases parameters?
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 removed the flag from being passed around just import the global directly now.
|
||
it('fails to find comments for a sub case', async () => { | ||
const { body } = await supertest | ||
.get(`${CASES_URL}/invalid-id/comments/_find?subCaseId=somevalue`) |
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.
Maybe I am missing something, but I cannot see how this test test the scenario described. We don't have comments, caseId is invalid, subCaseId is invalid so the total will always be 0
.
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.
Good point, I have the routes through now 👍
x-pack/test/case_api_no_sub_cases_integration/basic/tests/cases/comments/delete_comment.ts
Outdated
Show resolved
Hide resolved
x-pack/test/case_api_no_sub_cases_integration/basic/tests/cases/comments/get_all_comments.ts
Outdated
Show resolved
Hide resolved
@@ -63,47 +56,78 @@ export default ({ getService }: FtrProviderContext): void => { | |||
expect(comments.length).to.eql(2); | |||
}); | |||
|
|||
it('should get comments from a case and its sub cases', 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.
These tests were indented and placed in a new describe block.
const { newSubCaseInfo: caseInfo } = await createSubCase({ supertest, actionID }); | ||
expect(caseInfo.subCases![0].id).to.not.eql(undefined); | ||
// ENABLE_SUB_CASES: once the case connector feature is completed unskip these tests | ||
describe.skip('delete_sub_cases', () => { |
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.
These were indented.
@@ -5,8 +5,6 @@ | |||
* 2.0. | |||
*/ | |||
|
|||
import { DEFAULT_MAX_SIGNALS } from '../../security_solution/common/constants'; |
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 need to remove this import to avoid the circular import issue.
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.
Nicely done, good job!!!
💚 Build Succeeded
Metrics [docs]Async chunks
Page load bundle
Saved Objects .kibana field count
History
To update your PR or re-run it, just comment with: |
* Adding feature flag for sub cases * Disabling case as a connector in security solution * Fix connector test * Switching feature flag to global variable * Removing this.config use * Fixing circular import and renaming flag
This PR adds a feature flag to disable the sub cases feature by default. This is necessary because the sub cases feature won't ship in 7.13.
To enable the feature set the
ENABLE_CASE_CONNECTOR
flag totrue
.The cases plugin will no longer register case as a connector by default. It will only be registered if the flag is enabled. This is different than what is done in 7.12 and 7.11.
The work for this feature is being tracked here: #94115
API integration tests
I added some tests to ensure that the sub case routes resulted in a 404 response and some tests to ensure that the routes that used the
subCaseId
ignored it or errored with a 400 accordingly.