[Cases] [Security Solution] New cases subfeatures, add comments and reopen cases #194898

kqualters-elastic · 2024-10-04T06:02:24Z

Summary

This pr adds 2 new sub feature permissions to the cases plugin in stack/security/observability, that behave as follows. The first is for controlling the ability to reopen cases. When Cases has the read permission, and the reopen permission is not enabled, users have permissions as before. When enabled, users can move cases from closed to open/in progress, but nothing else. If a user has all and this permission, they can do anything as before, if the option is unselected, they can change case properties, and change a case from open to anything, in progress to anything, but if the case is closed, are unable to reopen it.

The 2nd permission is 'Add comment'. When enabled and the user has case read permissions, users can add comments, but not make any other changes to the case. When the user has read and this deselected, read functions as before. When a user has this permission and cases is all, this functions as all. When they have all but this permission is deselected, the user can do everything normally, except add cases comments.

Checklist

Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
Documentation was added for features that require explanation or tutorials
Unit or functional tests were updated or added to match the most common scenarios

elasticmachine · 2024-10-07T02:31:41Z

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)

jloleysens

Focussed on features plugin and left a few nits that would be nice to address before merging.

jloleysens · 2024-10-07T08:34:29Z

x-pack/plugins/features/common/feature_kibana_privileges.ts

+    createComment?: readonly string[];
+    reopenCases?: readonly string[];


Nit: missing doc comments like other interface members

Will update, although I think the grammar for all of these doc blocks is a little unclear. Proposed change for all of them: "List of case owners whose users should have settings access when granted this privilege.", "List of case owners whose users should have comment creation access when granted this privilege." etc. cc @cnasikas

Sounds good to me. Also could you please add a comment on top of the update to mention that it does not include reopening a case?

jloleysens · 2024-10-07T08:40:45Z

x-pack/plugins/features/server/feature_privilege_iterator/feature_privilege_iterator.ts

@@ -151,6 +151,14 @@ function mergeWithSubFeatures(
        mergedConfig.cases?.settings ?? [],
        subFeaturePrivilege.cases?.settings ?? []
      ),
+      createComment: mergeArrays(


nit: would you mind including these in the relevant unit test in x-pack/plugins/features/server/feature_privilege_iterator/feature_privilege_iterator.test.ts

ya will update, although that seems like something that typescript should catch

+1 for adding unit tests.

cauemarcondes

Obs shared LGTM

lgestc

looks okay, will also try to test it later today

cnasikas

Hey! I did a first pass of the PR focusing mostly on the backend code. I left some comments.

cnasikas · 2024-10-08T13:53:00Z

x-pack/plugins/cases/common/constants/index.ts

@@ -171,6 +171,8 @@ export const DELETE_CASES_CAPABILITY = 'delete_cases' as const;
 export const PUSH_CASES_CAPABILITY = 'push_cases' as const;
 export const CASES_SETTINGS_CAPABILITY = 'cases_settings' as const;
 export const CASES_CONNECTORS_CAPABILITY = 'cases_connectors' as const;
+export const REOPEN_CASES_CAPABILITY = 'reopen_cases' as const;
+export const COMMENT_CASES_CAPABILITY = 'create_comment' as const;


super nit: COMMENT_CASES_CAPABILITY -> CREATE_COMMENT_CAPABILITY

cnasikas · 2024-10-08T13:53:59Z

x-pack/plugins/features/common/feature_kibana_privileges.ts

+    createComment?: readonly string[];
+    reopenCases?: readonly string[];


Sounds good to me. Also could you please add a comment on top of the update to mention that it does not include reopening a case?

cnasikas · 2024-10-08T13:55:46Z

x-pack/plugins/features/server/feature_privilege_iterator/feature_privilege_iterator.ts

@@ -151,6 +151,14 @@ function mergeWithSubFeatures(
        mergedConfig.cases?.settings ?? [],
        subFeaturePrivilege.cases?.settings ?? []
      ),
+      createComment: mergeArrays(


+1 for adding unit tests.

cnasikas · 2024-10-08T15:55:11Z

x-pack/packages/security-solution/features/src/product_features_keys.ts

@@ -148,6 +148,8 @@ export enum SecuritySubFeatureId {
 export enum CasesSubFeatureId {
  deleteCases = 'deleteCasesSubFeature',
  casesSettings = 'casesSettingsSubFeature',
+  addComment = 'addCommentSubFeature',


nit: Let's stick with the createComment* terminology.

cnasikas · 2024-10-08T15:57:58Z

x-pack/packages/security/authorization_core/src/privileges/feature_privilege_builder/cases.ts

+const createCommentOperations = ['createComment'] as const;
+const reopenOperations = ['reopenCases'] as const;


nit: Because they are single operations I think it is better if we do const createComment = 'createComment' etc. Wdyt?

I would prefer actually if we left this as is for consistency in the getCasesPrivilege fn and the way allOperations is built. Also the naming paradigm operations maintains that consistency as well. Willing to make the change if you'd still like us to, but think this way is a bit simpler

cnasikas · 2024-10-08T16:55:42Z

x-pack/plugins/cases/public/components/actions/status/use_status_action.test.tsx

@@ -51,15 +51,15 @@ describe('useStatusAction', () => {
        },
        Object {
          "data-test-subj": "cases-bulk-action-status-in-progress",
-          "disabled": false,


Let's keep the test with disabled: false and then add some tests that test the disabled behavior.

cnasikas · 2024-10-08T16:57:14Z

x-pack/plugins/cases/public/components/all_cases/use_bulk_actions.test.tsx

@@ -52,47 +52,6 @@ describe('useBulkActions', () => {
            Object {
              "id": 0,
              "items": Array [
-                Object {


Let's keep the test without removing the actions and then add some tests that test the disabled behavior.

cnasikas · 2024-10-08T16:59:40Z

x-pack/plugins/cases/public/components/user_actions/use_user_permissions.tsx

+  const canChangeStatus = useMemo(() => {
+    // User has full permissions
+    if (permissions.update && permissions.reopenCases) {
+      return false;


Should we return true?

Yea, had to rethink this a bit

cnasikas · 2024-10-08T17:00:15Z

x-pack/plugins/cases/public/components/user_actions/use_user_permissions.tsx

+    // User has full permissions
+    if (permissions.update && permissions.reopenCases) {
+      return false;
+    } else {


nit: What do you think of escaping early the if statements?

Rethought this file a bit. Hopefully it makes more sense now

cnasikas · 2024-10-08T17:02:48Z

x-pack/plugins/cases/public/components/user_actions/use_user_permissions.tsx

+import { useCasesContext } from '../cases_context/use_cases_context';
+import { CaseStatuses } from '../../../common/types/domain';
+
+export const useUserPermissions = ({ status }: { status?: CaseStatuses }) => {


nit: status -> statusToAuthorize

dominiqueclarke

obs-ux-management changes LGTM

semd

Security Threat Hunting Explore code LGTM

…-fix'

ashokaditya · 2024-11-01T09:36:51Z

packages/kbn-es/src/serverless_resources/project_roles/security/roles.yml

@@ -46,7 +46,7 @@ viewer:
        - feature_siem.read
        - feature_siem.read_alerts
        - feature_siem.endpoint_list_read
-        - feature_securitySolutionCases.read
+        - feature_securitySolutionCasesV2.read


Are these new privileges for all these roles also updated in the elasticsearch-controller repo? The privileges in this file here should be a copy of those. If not, I'd suggest you create a PR on the other repo first, to update the privileges before merging this PR.

The privileges in roles.yml, security_roles.json, roles.yml and project_controller_security_roles.yml need to be in sync with the ones in elasticsearch-controller for our testing needs.

If not, I'd suggest you create a PR on the other repo first, to update the privileges before merging this PR.

As I explained in https://github.com/elastic/kibana/pull/194898/files#r1801715345, it might be easier to do it the other way around: first merge the PR, wait until the changes reach production, and then drop legacy privileges from the predefined roles. Alternatively, you could update the predefined roles first, but you’d need to keep both old and new privileges since we’ll have Kibana pods running on different versions simultaneously, and later update predefined roles once again to remove legacy privileges.

azasypkin

LGTM from the AppEx Platform Security side (code review only). I’ve left a few minor suggestions and a few items I consider important to address or discuss before merging.

azasypkin · 2024-11-04T13:58:14Z

packages/kbn-es/src/serverless_resources/project_roles/security/roles.yml

@@ -46,7 +46,7 @@ viewer:
        - feature_siem.read
        - feature_siem.read_alerts
        - feature_siem.endpoint_list_read
-        - feature_securitySolutionCases.read
+        - feature_securitySolutionCasesV2.read


If not, I'd suggest you create a PR on the other repo first, to update the privileges before merging this PR.

As I explained in https://github.com/elastic/kibana/pull/194898/files#r1801715345, it might be easier to do it the other way around: first merge the PR, wait until the changes reach production, and then drop legacy privileges from the predefined roles. Alternatively, you could update the predefined roles first, but you’d need to keep both old and new privileges since we’ll have Kibana pods running on different versions simultaneously, and later update predefined roles once again to remove legacy privileges.

azasypkin · 2024-11-04T14:05:13Z

x-pack/packages/security-solution/features/src/cases/v1_features/kibana_features.ts

+        replacedBy: [
+          {
+            feature: CASES_FEATURE_ID_V2,
+            privileges: ['minimal_all', 'create_comment', 'case_reopen'],


Important
I believe we agreed in #194898 (comment) to use "extended" syntax to have separate definition for default and minimal privilege variants (for both all and read)?

azasypkin · 2024-11-04T14:10:01Z

x-pack/packages/security-solution/features/src/cases/v2_features/kibana_features.ts

    catalogue: [APP_ID],
    cases: [APP_ID],
    privileges: {
      all: {
        api: apiTags.all,
-        app: [CASES_FEATURE_ID, 'kibana'],
+        app: [SECURITY_SOLUTION_CASES_APP_ID, 'kibana'],


Warning
Did you intentionally update app only in all and keep the old value for read?

no, thanks for catching

azasypkin · 2024-11-04T14:12:31Z

x-pack/packages/security-solution/features/src/cases/v2_features/kibana_sub_features.ts

+            api: apiTags.all,
+            id: 'case_reopen',
+            name: i18n.translate(
+              'securitySolutionPackages.features.featureRegistry.reopenCaseubFeatureDetails',


Tip
Typo

Suggested change

'securitySolutionPackages.features.featureRegistry.reopenCaseubFeatureDetails',

'securitySolutionPackages.features.featureRegistry.reopenCaseSubFeatureDetails',

@azasypkin I believe this has been addressed

azasypkin · 2024-11-04T14:12:47Z

x-pack/packages/security-solution/features/src/cases/v2_features/kibana_sub_features.ts

+  };
+  const casesreopenCaseubFeature: SubFeatureConfig = {
+    name: i18n.translate(
+      'securitySolutionPackages.features.featureRegistry.reopenCaseubFeatureName',


Tip
Typo (here and in other plugins)

Suggested change

'securitySolutionPackages.features.featureRegistry.reopenCaseubFeatureName',

'securitySolutionPackages.features.featureRegistry.reopenCaseSubFeatureName',

I believe this has been addressed

azasypkin · 2024-11-04T14:41:13Z

x-pack/packages/security-solution/features/src/cases/v2_features/kibana_sub_features.ts

@@ -0,0 +1,178 @@
+/*


Note
/rant mode on
Having the sub-feature definitions separated from the feature definitions makes auditing ("what is granting what") so much harder!
/rant mode off

Yea, this decision predates this work, but completely understand 😅

azasypkin · 2024-11-04T14:49:52Z

x-pack/plugins/observability_solution/observability/server/features/cases_v1.ts

+        read: [...filesSavedObjectTypes],
+      },
+      ui: casesCapabilities.all,
+      replacedBy: [


Important
Same comment here: I believe we agreed in #194898 (comment) to use "extended" syntax to have separate definition for default and minimal privilege variants (for both all and read)?

azasypkin · 2024-11-04T15:09:53Z

x-pack/test/ui_capabilities/security_and_spaces/tests/catalogue.ts

@@ -72,6 +72,8 @@ export default function catalogueTests({ getService }: FtrProviderContext) {
              uiCapabilities.value!.catalogue,


Note
I believe you’ll be able to revert all changes in x-pack/test/ui_capabilities once I merge #198656. If I merge it before your PR, you’ll need to revert these changes; otherwise, I’ll revert them in my PR before merging.

#198656 is merged, can you please try to revert changes in x-pack/test/ui_capabilities and see if the tests pass?

azasypkin · 2024-11-04T15:11:01Z

x-pack/test/ui_capabilities/spaces_only/tests/nav_links.ts

+              uiCapabilities.value!.navLinks;
+            const {
+              kibana: _,
+              securitySolutionCases: __,


Should be addressed in #198656 and all changes in x-pack/test/ui_capabilities made in this PR can be reverted.

azasypkin · 2024-11-04T15:23:00Z

x-pack/test/security_api_integration/tests/features/cases_feature_permissions.ts

+      });
+    });
+
+    it('cases permissions are properly handled for deprecated privileges', async () => {


question: would it be possible to add another test that validates that a user with the deprecated all privilege (v1) can still reopen the case and comment on it, as well as a user with the non-deprecated all privilege? /cc @cnasikas

+1 to that. This is the most important scenario we would like to test.

…fix'

cnasikas

I did another pass on the PR. I hope this is the final one 🙂. I noticed that there are unaddressed comments from the previous reviews. Also, the following files are missing unit tests:

x-pack/plugins/cases/server/authorization/audit_logger.ts
x-pack/plugins/cases/public/components/user_actions/index.tsx

We also missing integration tests for the reopen sub privilege like in x-pack/test/cases_api_integration/security_and_spaces/tests/trial/create_comment_sub_privilege.ts.

Finally, it would be nice if we could add some tests for the files (you cannot create files if you do not have the create comment subfeature privilege) in x-pack/test/api_integration/apis/cases/files.ts

cnasikas · 2024-11-06T07:49:54Z

x-pack/plugins/cases/common/utils/api_tags.ts

@@ -40,5 +41,6 @@ export const getApiTags = (owner: Owner): CasesApiTags => {
      read,
    ] as const,
    delete: [deleteTag] as const,
+    createComment: [create, CREATE_COMMENT_API_TAG] as const,


We do not need the CREATE_COMMENT_API_TAG, only the create. The Cases API will perform its own authorization inside, so it is fine not to define any tags for the Cases APIs. For the File Cases API, though, which is not controlled by the cases code, we should have the create (tag only for files) as you have.

Suggested change

createComment: [create, CREATE_COMMENT_API_TAG] as const,

createComment: [create] as const,

cnasikas · 2024-11-06T08:11:40Z

x-pack/plugins/cases/server/authorization/authorization.test.ts

+        })
+      ).resolves.not.toThrow();
+
+      expect(mockLogger.log.mock.calls).toMatchSnapshot();


Could you please add a check that we call the checkPrivileges with the correct requiredPrivileges? You can do it expect(checkRequestReturningHasAllAsTrue.mock.calls[0]).toMatchInlineSnapshot(...). Also, I think is better to have two tests one for checking the operations and one for checking the logging.

cnasikas · 2024-11-06T08:14:36Z

x-pack/plugins/cases/server/authorization/audit_logger.ts

  }) {
    const ownerMsg = owners.length <= 0 ? 'of any owner' : `with owners: "${owners.join(', ')}"`;
+    const operations = Array.isArray(operation) ? operation : [operation];
+    const operationVerbs = [...new Set(operations.map((op) => op.verbs.present))].join(', ');
+    const operationDocTypes = [...new Set(operations.map((op) => op.docType))].join(', ');
    /**
     * This will take the form:
     * `Unauthorized to create case with owners: "securitySolution, observability"`
     * `Unauthorized to access cases of any owner`


nit: Could we add an example for multiple operations?

cnasikas · 2024-11-06T08:20:00Z

...ck/plugins/security_solution/server/lib/product_features_service/product_features_service.ts

@@ -96,6 +113,7 @@ export class ProductFeaturesService {

    const casesProductFeaturesConfig = configurator.cases();
    this.casesProductFeatures.setConfig(casesProductFeaturesConfig);
+    this.casesProductV2Features.setConfig(casesProductFeaturesConfig);


Is it ok if the two features have the same configuration (casesProductFeaturesConfig)? Not sure how the ProductFeaturesService works tbh 🙂.

cnasikas · 2024-11-06T08:23:30Z

x-pack/test_serverless/shared/lib/security/kibana_roles/project_controller_security_roles.yml

@@ -488,6 +488,8 @@ soc_manager:
    - application: "kibana-.kibana"
      privileges:
        - feature_ml.read
+        - feature_generalCases.all
+        - feature_generalCasesV2.all


generalCases and generalCasesV2 features are used for Cases in the stack management page. Stack cases are not available in the Security project. Do we need it here?

cnasikas · 2024-11-06T08:57:24Z

x-pack/test/security_api_integration/tests/features/cases_feature_permissions.ts

+      });
+    });
+
+    it('cases permissions are properly handled for deprecated privileges', async () => {


+1 to that. This is the most important scenario we would like to test.

cnasikas · 2024-11-06T09:08:15Z

x-pack/test/security_api_integration/tests/features/cases_feature_permissions.ts

I think that the tests should be owned by ResponseOps and not the Kibana security team as solutions use the framework to deprecate their features. You could add tests in x-pack/test/api_integration/apis/cases/privileges.ts, create dedicated users (x-pack/test/api_integration/apis/cases/common/users.ts) and roles (x-pack/test/api_integration/apis/cases/common/roles.ts) for the new features, and use the old users for the old features. This way you could avoid creating roles on the fly and also test all solutions at the same time. Finally, you can use a lot of our utility functions exported from cases_api_integration/common/lib/api.

cnasikas · 2024-11-06T09:10:34Z

...k/test/cases_api_integration/security_and_spaces/tests/trial/create_comment_sub_privilege.ts

+        });
+      });
+
+      // Delete


nit: The test is for updating.

cnasikas · 2024-11-06T09:15:02Z

x-pack/packages/security-solution/features/src/cases/v2_features/kibana_sub_features.ts

+        groupType: 'independent',
+        privileges: [
+          {
+            api: apiTags.all,


I think we should remove the tags here.

cnasikas · 2024-11-06T10:02:54Z

x-pack/test/cases_api_integration/common/lib/authentication/roles.ts

+    kibana: [
+      {
+        feature: {
+          securitySolutionFixture: ['minimal_all'],


Shouldn't this be cases_delete?

no_delete right?

cnasikas · 2024-11-06T10:26:45Z

x-pack/test/api_integration/apis/cases/common/roles.ts

I think is better to keep the old privileges. This way we can be sure that the tests in x-pack/test/api_integration/apis/cases/privileges.ts still working as expected with the old deprecated features.

cnasikas · 2024-11-06T10:37:59Z

I also found a small bug. If I do not have access to reopen a case I can select the status dropdown but it is empty. I think we should not allow users to click and hide the caret (down arrow) when they do not have access to reopen.

kqualters-elastic · 2024-11-07T04:45:29Z

@cnasikas for x-pack/plugins/cases/public/components/user_actions/index.tsx , there were no logic changes at all, merely moving some logic to a shared hook that has tests, and renamed a variable. Any new tests would be testing cases that did not exist before, and the existing tests passing without needing any changes should be proof enough of this.

…fix'

…es-subfeatures-main

elasticmachine · 2024-11-14T05:28:08Z

⏳ Build in-progress, with failures

Buildkite Build
Commit: ca96951
Storybooks Preview
Cloud Deployment
Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-194898-ca96951c6d17

Failed CI Steps

Test Failures

[job] [logs] FTR Configs #9 / cases files successful requests users with all privileges scenario user: sec_all_user_api_int fileKind: securitySolutionFilesCases delete created file after test should list files
[job] [logs] FTR Configs #9 / cases files successful requests users with all privileges scenario user: sec_all_user_api_int fileKind: securitySolutionFilesCases delete created file after test should list files
[job] [logs] FTR Configs #80 / cases security and spaces enabled: basic Common delete_cases rbac files should delete a case when the user has access to delete the case and files
[job] [logs] FTR Configs #80 / cases security and spaces enabled: basic Common delete_cases rbac files should delete a case when the user has access to delete the case and files
[job] [logs] x-pack/test/cases_api_integration/security_and_spaces/config_trial.ts / cases security and spaces enabled: trial Common delete_cases rbac files should delete a case when the user has access to delete the case and files
[job] [logs] x-pack/test/cases_api_integration/security_and_spaces/config_trial.ts / cases security and spaces enabled: trial Common delete_cases rbac files should delete a case when the user has access to delete the case and files
[job] [logs] FTR Configs #63 / Screenshots - serverless observability UI response ops docs observability cases list view case detail screenshot
[job] [logs] FTR Configs #63 / Screenshots - serverless observability UI response ops docs observability cases list view case detail screenshot
[job] [logs] FTR Configs #62 / security APIs - Features deprecated features all deprecated features are known
[job] [logs] FTR Configs #62 / security APIs - Features deprecated features all deprecated features are known
[job] [logs] Jest Tests #1 / UserActionsList renders list correctly with isExpandable option

History

cc @adcoelho @cnasikas

kqualters-elastic added v8.16.0 v9.0.0 release_note:feature Makes this part of the condensed release notes backport:version Backport to applied version labels labels Oct 7, 2024

kqualters-elastic marked this pull request as ready for review October 7, 2024 02:30

kqualters-elastic requested review from a team as code owners October 7, 2024 02:30

botelastic bot added ci:project-deploy-observability Create an Observability project Team:obs-ux-management Observability Management User Experience Team labels Oct 7, 2024

This comment was marked as outdated.

Sign in to view

jloleysens approved these changes Oct 7, 2024

View reviewed changes

cauemarcondes approved these changes Oct 7, 2024

View reviewed changes

azasypkin self-requested a review October 7, 2024 11:15

lgestc approved these changes Oct 8, 2024

View reviewed changes

cnasikas reviewed Oct 8, 2024

View reviewed changes

smith added the apm:review label Oct 10, 2024

dominiqueclarke approved these changes Oct 11, 2024

View reviewed changes

semd approved these changes Oct 14, 2024

View reviewed changes

michaelolo24 force-pushed the cases-subfeatures-main branch from 8ec412d to 10d7756 Compare October 14, 2024 21:34

kqualters-elastic added 5 commits October 14, 2024 19:10

Cases new subfeatures, add comments and reopen cases

151f3e8

Fix types

fa4cd43

Add to obs and security solution

ad8b154

Remove unneeded changes

c7e7ffd

Update snapshots

b15b1f5

kqualters-elastic and others added 3 commits October 30, 2024 22:32

Remove commented out code

af31474

Merge remote-tracking branch 'upstream/main' into cases-subfeatures-main

cf33281

[CI] Auto-commit changed files from 'node scripts/eslint --no-cache -…

8532f42

…-fix'

ashokaditya reviewed Nov 1, 2024

View reviewed changes

azasypkin self-requested a review November 4, 2024 13:50

azasypkin reviewed Nov 4, 2024

View reviewed changes

kqualters-elastic and others added 5 commits November 5, 2024 06:00

PR feedback, add re-open tests

54da9c3

Merge remote-tracking branch 'upstream/main' into cases-subfeatures-main

042b461

[CI] Auto-commit changed files from 'node scripts/lint_ts_projects --…

709e653

…fix'

Use read and minimal_read for read perms in v2

c32846d

Fix types

d735c65

cnasikas reviewed Nov 6, 2024

View reviewed changes

Merge remote-tracking branch 'upstream/main' into cases-subfeatures-main

ac1eb26

PhilippeOberti added v8.17.0 and removed v8.16.0 labels Nov 7, 2024

kqualters-elastic and others added 11 commits November 13, 2024 08:41

Remove unneeded changes, add api int tests, fix some types

4927d34

Merge remote-tracking branch 'upstream/main' into cases-subfeatures-main

4daca54

PR feedback, fix tests/types

9b6b3ef

Merge remote-tracking branch 'upstream/main' into cases-subfeatures-main

38cce3f

[CI] Auto-commit changed files from 'node scripts/lint_ts_projects --…

5caf97e

…fix'

Remove create_comment from cases v1

5cb7c46

Merge remote-tracking branch 'origin/cases-subfeatures-main' into cas…

c307b1c

…es-subfeatures-main

Fix create/createComment with v1

45cd5dd

Fix Jest tests

f5dd06c

Fix types

d449b8e

Merge remote-tracking branch 'upstream/main' into cases-subfeatures-main

ca96951

		createComment?: readonly string[];
		reopenCases?: readonly string[];

		const createCommentOperations = ['createComment'] as const;
		const reopenOperations = ['reopenCases'] as const;

	'securitySolutionPackages.features.featureRegistry.reopenCaseubFeatureDetails',
	'securitySolutionPackages.features.featureRegistry.reopenCaseSubFeatureDetails',

		@@ -72,6 +72,8 @@ export default function catalogueTests({ getService }: FtrProviderContext) {
		uiCapabilities.value!.catalogue,

	createComment: [create, CREATE_COMMENT_API_TAG] as const,
	createComment: [create] as const,

[Cases] [Security Solution] New cases subfeatures, add comments and reopen cases #194898

Are you sure you want to change the base?

[Cases] [Security Solution] New cases subfeatures, add comments and reopen cases #194898

Conversation

kqualters-elastic commented Oct 4, 2024 • edited Loading

Summary

Checklist

elasticmachine commented Oct 7, 2024

This comment was marked as outdated.

jloleysens left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cauemarcondes left a comment

Choose a reason for hiding this comment

lgestc left a comment

Choose a reason for hiding this comment

cnasikas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dominiqueclarke left a comment

Choose a reason for hiding this comment

semd left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azasypkin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cnasikas left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cnasikas Nov 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kqualters-elastic commented Oct 4, 2024 •

edited

Loading

cnasikas left a comment •

edited

Loading

cnasikas Nov 6, 2024 •

edited

Loading

cnasikas commented Nov 6, 2024 •

edited

Loading

kqualters-elastic commented Nov 7, 2024 •

edited

Loading

elasticmachine commented Nov 14, 2024 •

edited

Loading