[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

azasypkin

LGTM, thanks! Left a few minor nits.

azasypkin · 2024-11-19T16:54:33Z

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

+      notice: i18n.translate(
+        'securitySolutionPackages.features.featureRegistry.linkSecuritySolutionCase.deprecationMessage',
+        {
+          defaultMessage:


Note
We don’t need to do anything right now, but eventually, when we start displaying this to our users, we might need to rephrase it since interactive users won’t understand what CASES_FEATURE_ID_V2 means.

azasypkin · 2024-11-19T17:02:20Z

x-pack/plugins/cases/server/features/v1.ts

+          minimal: [
+            {
+              feature: FEATURE_ID_V2,
+              privileges: ['minimal_all', 'create_comment', 'case_reopen'],


I think we sorted this out! We only need minimal_all, create_comment, case_reopen.

azasypkin · 2024-11-19T17:03:00Z

x-pack/plugins/cases/server/features/v1.ts

@@ -97,6 +123,7 @@ export const getCasesKibanaFeature = (): KibanaFeatureConfig => {
                  delete: [APP_ID],
                },
                ui: capabilities.delete,
+                replacedBy: [{ feature: FEATURE_ID_V2, privileges: ['cases_delete'] }],


Can we use const here (same for settings)?

Suggested change

replacedBy: [{ feature: FEATURE_ID_V2, privileges: ['cases_delete'] }],

replacedBy: [{ feature: FEATURE_ID_V2, privileges: [CASES_DELETE_SUB_PRIVILEGE_ID] }],

azasypkin · 2024-11-19T17:14:42Z

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

@@ -148,15 +148,15 @@ export default function catalogueTests({ getService }: FtrProviderContext) {
            expect(uiCapabilities.value!.catalogue).to.eql(expected);
            break;
          }
+          case 'global_read at nothing_space':


question: do you need this change? I believe these xxx at nothing_space should stay where they were, under the corresponding the nothing_space has no Kibana features enabled,.... comment.

azasypkin · 2024-11-19T17:15:20Z

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

@@ -80,11 +80,11 @@ export default function navLinksTests({ getService }: FtrProviderContext) {
              navLinksBuilder.only('kibana', 'foo', 'management')
            );
            break;
+          case 'foo_all at nothing_space':


nit: same comment here, there is no need to re-order these case branches.

azasypkin · 2024-11-19T17:17:02Z

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

@@ -504,6 +506,9 @@ soc_manager:
        - feature_siem.execute_operations_all
        - feature_siem.scan_operations_all
        - feature_securitySolutionCases.all
+        - feature_securitySolutionCasesV2.all
+        - feature_observabilityCases.all
+        - feature_observabilityCasesV2.all


I'm not quite sure why we need both v1 and v2 privileges in this file, cannot we just keep v2 ones?

github-actions · 2024-11-19T17:17:31Z

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

/oblt-deploy : Deploy a Kibana instance using the Observability test environments.
run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

kqualters-elastic · 2024-11-19T17:32:16Z

I'm not quite sure why we need both v1 and v2 privileges in this file, cannot we just keep v2 ones?

@azasypkin good catch, those were intended to be done in conjunction with https://github.com/elastic/elasticsearch-controller/pull/762 but since we are going to merge this pr, and then after the next serverless release, convert to v2 instead of having both defined at once, I removed them in 3aa925d

elasticmachine · 2024-11-19T18:33:07Z

💚 Build Succeeded

Buildkite Build
Commit: 3aa925d
Storybooks Preview
Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-194898-3aa925d2566b

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
`cases`	821	823	+2

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
`cases`	95	106	+11
`observability`	686	687	+1
total			+12

Async chunks

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

id	before	after	diff
`cases`	491.9KB	492.7KB	+846.0B
`ml`	4.7MB	4.7MB	+6.0B
`observability`	472.5KB	472.5KB	+7.0B
`securitySolution`	13.4MB	13.4MB	+147.0B
`threatIntelligence`	57.3KB	57.3KB	+7.0B
total			+1013.0B

Page load bundle

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

id	before	after	diff
`cases`	158.3KB	159.1KB	+791.0B
`observability`	103.6KB	103.7KB	+74.0B
`observabilityShared`	93.6KB	93.7KB	+64.0B
`securitySolution`	86.1KB	86.1KB	+4.0B
total			+933.0B

Unknown metric groups

API count

id	before	after	diff
`cases`	115	126	+11
`observability`	694	695	+1
total			+12

ESLint disabled line counts

id	before	after	diff
`@kbn/test-suites-xpack`	722	723	+1

Total ESLint disabled count

id	before	after	diff
`@kbn/test-suites-xpack`	747	748	+1

Unreferenced deprecated APIs

id	before	after	diff
`cases`	0	1	+1
`observability`	0	1	+1
total			+2

History

cc @adcoelho @cnasikas

kibanamachine · 2024-11-19T19:16:05Z

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/11920118581

…eopen cases (elastic#194898) ## 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 - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: Michael Olorunnisola <michael.olorunnisola@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 0afae42)

kibanamachine · 2024-11-19T19:26:50Z

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

… and reopen cases (#194898) (#200807) # Backport This will backport the following commits from `main` to `8.x`: - [[Cases] [Security Solution] New cases subfeatures, add comments and reopen cases (#194898)](#194898)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)  Co-authored-by: Kevin Qualters <56408403+kqualters-elastic@users.noreply.github.com>

… tests for failing case (#201517) ## Summary Currently, the partitionPatchRequest in x-pack/plugins/cases/server/client/cases/bulk_update.ts will not check a case properly if a case is being re-opened, instead of an else if in the loop comparing cases to cases in the request, the status logic should be outside of this set of if statements. If a case is being re-opened, the final else is never run, and casesToAuthorize is 0. This results in ensureAuthorized being called with an empty array of entities, and so the check always succeeds. To fix this, reopenedCases is still populated in the same loop, just not when casesToAuthorize logic is running as well. Also adds some missing tests for this and the create comment permission as requested in #194898. ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios

… tests for failing case (elastic#201517) ## Summary Currently, the partitionPatchRequest in x-pack/plugins/cases/server/client/cases/bulk_update.ts will not check a case properly if a case is being re-opened, instead of an else if in the loop comparing cases to cases in the request, the status logic should be outside of this set of if statements. If a case is being re-opened, the final else is never run, and casesToAuthorize is 0. This results in ensureAuthorized being called with an empty array of entities, and so the check always succeeds. To fix this, reopenedCases is still populated in the same loop, just not when casesToAuthorize logic is running as well. Also adds some missing tests for this and the create comment permission as requested in elastic#194898. ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios (cherry picked from commit 1c3bcea)

…gration tests for failing case (#201517) (#201554) # Backport This will backport the following commits from `main` to `8.17`: - [[Cases] Fix an issue with the reopen case permission, add integration tests for failing case (#201517)](#201517)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)  Co-authored-by: Kevin Qualters <56408403+kqualters-elastic@users.noreply.github.com>

…eopen cases (elastic#194898) ## 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 - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: Michael Olorunnisola <michael.olorunnisola@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

… tests for failing case (elastic#201517) ## Summary Currently, the partitionPatchRequest in x-pack/plugins/cases/server/client/cases/bulk_update.ts will not check a case properly if a case is being re-opened, instead of an else if in the loop comparing cases to cases in the request, the status logic should be outside of this set of if statements. If a case is being re-opened, the final else is never run, and casesToAuthorize is 0. This results in ensureAuthorized being called with an empty array of entities, and so the check always succeeds. To fix this, reopenedCases is still populated in the same loop, just not when casesToAuthorize logic is running as well. Also adds some missing tests for this and the create comment permission as requested in elastic#194898. ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios

…eopen cases (elastic#194898) ## 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 - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: Michael Olorunnisola <michael.olorunnisola@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

… tests for failing case (elastic#201517) ## Summary Currently, the partitionPatchRequest in x-pack/plugins/cases/server/client/cases/bulk_update.ts will not check a case properly if a case is being re-opened, instead of an else if in the loop comparing cases to cases in the request, the status logic should be outside of this set of if statements. If a case is being re-opened, the final else is never run, and casesToAuthorize is 0. This results in ensureAuthorized being called with an empty array of entities, and so the check always succeeds. To fix this, reopenedCases is still populated in the same loop, just not when casesToAuthorize logic is running as well. Also adds some missing tests for this and the create comment permission as requested in elastic#194898. ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios

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 removed the ci:project-deploy-observability Create an Observability project label Nov 19, 2024

azasypkin approved these changes Nov 19, 2024

View reviewed changes

botelastic bot added the ci:project-deploy-observability Create an Observability project label Nov 19, 2024

kqualters-elastic added 2 commits November 19, 2024 17:18

Skip failing timeline test

245fd3c

PR feedback

3aa925d

kqualters-elastic enabled auto-merge (squash) November 19, 2024 18:06

kqualters-elastic merged commit 0afae42 into elastic:main Nov 19, 2024
53 checks passed

kibanamachine mentioned this pull request Nov 19, 2024

[8.x] [Cases] [Security Solution] New cases subfeatures, add comments and reopen cases (#194898) #200807

Merged

kqualters-elastic mentioned this pull request Nov 25, 2024

[Cases] Fix an issue with the reopen case permission, add integration tests for failing case #201517

Merged

1 task

cnasikas mentioned this pull request Nov 29, 2024

[Docs] 8.17.0 release notes #202021

Merged

kqualters-elastic mentioned this pull request Dec 3, 2024

[Request] Cases subfeatures elastic/security-docs#6266

Closed

cnasikas mentioned this pull request Dec 11, 2024

Add Commenting to Read-Only Cases #183083

Closed

This was referenced Dec 14, 2024

[DOCS] Add case subfeature privileges #204295

Merged

[Cases] New cases subfeature privileges elastic/observability-docs#4694

Merged

This was referenced Dec 17, 2024

[8.x](backport #4694) [Cases] New cases subfeature privileges elastic/observability-docs#4699

Open

[8.17](backport #4694) [Cases] New cases subfeature privileges elastic/observability-docs#4700

Open

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

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

	replacedBy: [{ feature: FEATURE_ID_V2, privileges: ['cases_delete'] }],
	replacedBy: [{ feature: FEATURE_ID_V2, privileges: [CASES_DELETE_SUB_PRIVILEGE_ID] }],

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

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

Conversation

kqualters-elastic commented Oct 4, 2024 • edited by kibanamachine 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

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

github-actions bot commented Nov 19, 2024

🤖 GitHub comments

kqualters-elastic commented Nov 19, 2024

elasticmachine commented Nov 19, 2024 • edited Loading

💚 Build Succeeded

Metrics [docs]

Module Count

Public APIs missing comments

Async chunks

Page load bundle

API count

ESLint disabled line counts

Total ESLint disabled count

Unreferenced deprecated APIs

History

kibanamachine commented Nov 19, 2024

kibanamachine commented Nov 19, 2024

💚 All backports created successfully

Questions ?

kqualters-elastic commented Oct 4, 2024 •

edited by kibanamachine

Loading

elasticmachine commented Nov 19, 2024 •

edited

Loading