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

[Cases] Adding feature flag for sub cases #95122

Merged
merged 9 commits into from
Mar 25, 2021

Conversation

jonathan-buttner
Copy link
Contributor

@jonathan-buttner jonathan-buttner commented Mar 22, 2021

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 to true.

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.

@jonathan-buttner jonathan-buttner added v8.0.0 release_note:skip Skip the PR/issue when compiling release notes Team:Threat Hunting Security Solution Threat Hunting Team Feature:Cases Cases feature v7.13.0 labels Mar 22, 2021
@@ -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
Copy link
Contributor Author

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

Copy link
Member

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?

Copy link
Contributor Author

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;
Copy link
Contributor Author

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?

Copy link
Contributor

@XavierM XavierM Mar 23, 2021

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

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 👍

@jonathan-buttner jonathan-buttner marked this pull request as ready for review March 23, 2021 14:04
@jonathan-buttner jonathan-buttner requested review from a team as code owners March 23, 2021 14:04
@elasticmachine
Copy link
Contributor

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,
Copy link
Member

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.

Copy link
Contributor Author

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
Copy link
Member

@cnasikas cnasikas Mar 24, 2021

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.

Copy link
Contributor

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
Copy link
Member

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 = {
Copy link
Member

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.

Copy link
Contributor Author

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
Copy link
Member

@cnasikas cnasikas Mar 24, 2021

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?

Copy link
Contributor Author

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`)
Copy link
Member

@cnasikas cnasikas Mar 24, 2021

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.

Copy link
Contributor Author

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 👍

@@ -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 () => {
Copy link
Contributor Author

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', () => {
Copy link
Contributor Author

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';
Copy link
Contributor Author

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.

Copy link
Contributor

@XavierM XavierM left a 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!!!

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
securitySolution 7.2MB 7.2MB -2.6KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
securitySolution 211.3KB 214.0KB +2.7KB

Saved Objects .kibana field count

Every field in each saved object type adds overhead to Elasticsearch. Kibana needs to keep the total field count below Elasticsearch's default limit of 1000 fields. Only specify field mappings for the fields you wish to search on or query. See https://www.elastic.co/guide/en/kibana/master/development-plugin-saved-objects.html#_mappings

id before after diff
cases-sub-case 17 - -17

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@jonathan-buttner jonathan-buttner merged commit 07f32d0 into elastic:master Mar 25, 2021
@jonathan-buttner jonathan-buttner deleted the disabled-sub-cases branch March 25, 2021 17:36
jonathan-buttner added a commit to jonathan-buttner/kibana that referenced this pull request Mar 25, 2021
* 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
jonathan-buttner added a commit that referenced this pull request Mar 25, 2021
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Cases Cases feature release_note:skip Skip the PR/issue when compiling release notes Team:Threat Hunting Security Solution Threat Hunting Team v7.13.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants