[ResponseOps][Rules] Create Rules APIs package by umbopepato · Pull Request #214187 · elastic/kibana

umbopepato · 2025-03-12T14:43:07Z

Summary

Creates a @kbn/response-ops-rules-apis package, following the proposed structure for ResponseOps Management Experiences package.
Moves relevant rules API fetchers and react-query hooks to the new package.
Adds an internal variant of the /api/alerting/rule_types endpoint (/internal/alerting/_rule_types), that returns the same value as the public one + the newly added internal solution field, that we don't want to expose publicly.

Verification steps

Create rules that fire alerts
Verify the usages of the moved/changed hooks, with limited privileges as well (i.e. only Rules Settings but not Stack Rules):
2.1. Stack management and Observability rules, rule details and alerts pages
2.2. Rules tab in the Connector editor flyout
2.3. Alerts table row actions (••• icon)
2.4. Tags filter in the rules list page
Using the DevTools, compare the response of the public and internal rule_types endpoins:
```
GET kbn:/api/alerting/rule_types
GET kbn:/internal/alerting/_rule_types
```
Checking that the solution field is present only in the internal one

References

Closes #213059

Checklist

Unit or functional tests were updated or added to match the most common scenarios

umbopepato · 2025-03-13T16:37:26Z

package.json

    "@kbn/response-ops-alerts-table": "link:src/platform/packages/shared/response-ops/alerts-table",
    "@kbn/response-ops-rule-form": "link:src/platform/packages/shared/response-ops/rule_form",
    "@kbn/response-ops-rule-params": "link:src/platform/packages/shared/response-ops/rule_params",
+    "@kbn/response-ops-rules-apis": "link:src/platform/packages/shared/response-ops/rules-apis",


Using kebab-case for package folders as requested by the operations team

umbopepato · 2025-03-13T16:37:59Z

src/platform/packages/shared/kbn-alerting-types/rule_types.ts

 import type { Filter } from '@kbn/es-query';
 import type { RuleNotifyWhenType, RRuleParams } from '.';

+export type RuleTypeSolution = 'observability' | 'security' | 'stack';


Had to move this here to avoid circular dependencies between plugins and packages

umbopepato · 2025-03-13T16:43:48Z

...form/packages/shared/kbn-alerts-ui-shared/src/common/hooks/use_get_rule_types_permissions.ts

 };

-export const useLoadRuleTypesQuery = ({
+export const useGetRuleTypesPermissions = ({


This hook was acting as the main rule types fetcher but also as privilege checker, returning computed values and not the original query. I extracted the react-query part that only fetches rule types to the new package, keeping this hook as a more privilege-checking-focused one (hence the new name). I avoided further refactors such as removing the returned rule types registry thing since there is a bit of filtering logic that might be worth studying better, and moving the hook to the new package as it's not properly a data-fetching hook (I'm wondering where these higher-level hooks should belong in our new package structure 🤔).

umbopepato · 2025-03-13T16:45:46Z

src/platform/packages/shared/response-ops/alerts-apis/constants.ts


 export const BASE_ALERTING_API_PATH = '/api/alerting';
-
-export const queryKeys = {


I moved all queryKeys and queryMutations of the new packages to dedicated files to increase visibility and because they aren't properly constants in the JS reference sense of the term

umbopepato · 2025-03-13T16:46:17Z

src/platform/packages/shared/response-ops/alerts-apis/hooks/use_get_muted_alerts_query.tsx

  notifications: NotificationsStart;
 }

+export const getKey = queryKeys.getMutedAlerts;


Trying out the WIP proposal of co-locating key creators by re-exporting them from the factory

what's the idea behind this?

umbopepato · 2025-03-13T16:48:43Z

src/platform/packages/shared/response-ops/rules-apis/query_keys.ts

+
+export const queryKeys = {
+  root: 'rules',
+  getRuleTags: ({


Trying out the WIP proposal of using the same exact name as the fetchFn for the key creator (for better discoverability)

umbopepato · 2025-03-13T16:50:22Z

...latform/plugins/shared/triggers_actions_ui/public/application/lib/rule_api/aggregate.test.ts

      ]
    `);
  });
-


Moved this test to its dedicated file in the new package

umbopepato · 2025-03-13T16:53:20Z

x-pack/solutions/observability/plugins/observability/public/pages/rules/rules.tsx

    filteredRuleTypes,
  });

-  const authorizedRuleTypes = [...ruleTypes.values()];


This is the same logic that the useLoadRuleTypesQuery was using internally, I used the calculated value from the hook directly

…-ops-rules-apis-package

umbopepato · 2025-03-24T09:25:58Z

@umbopepato I'm missing a link to the mentioned "proposed structure for ResponseOps Management Experiences package"

and #214187 (comment)

@jcger unfortunately I cannot link either document here but I shared them with you on other channels. The idea behind re-exporting the query key factory is to both have a centralized query key factory for each api package but also co-locate them along with their respective hooks for convenience. Trying it out with these new API packages, if we see it's not useful we can always remove it 🙂

…-ops-rules-apis-package

elasticmachine · 2025-03-24T16:11:26Z

💚 Build Succeeded

Buildkite Build
Commit: 74ed203

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
`alerting`	229	232	+3
`apm`	1896	1899	+3
`cases`	1015	1018	+3
`discover`	1179	1182	+3
`embeddableAlertsTable`	283	288	+5
`infra`	1454	1457	+3
`ml`	2403	2408	+5
`monitoring`	655	658	+3
`observability`	1313	1318	+5
`securitySolution`	7095	7098	+3
`slo`	1130	1133	+3
`synthetics`	1217	1220	+3
`transform`	716	719	+3
`triggersActionsUi`	837	841	+4
`uptime`	812	815	+3
total			+52

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
`@kbn/alerting-types`	248	249	+1
`triggersActionsUi`	525	520	-5
total			-4

Async chunks

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

id	before	after	diff
`alerting`	98.5KB	98.7KB	+276.0B
`apm`	2.5MB	2.5MB	+374.0B
`cases`	1.3MB	1.3MB	+283.0B
`discover`	951.1KB	951.5KB	+379.0B
`embeddableAlertsTable`	803.8KB	804.2KB	+390.0B
`infra`	1.2MB	1.2MB	+379.0B
`ml`	5.4MB	5.4MB	+416.0B
`monitoring`	642.4KB	642.8KB	+376.0B
`observability`	1.3MB	1.3MB	+224.0B
`securitySolution`	8.9MB	8.9MB	+305.0B
`slo`	921.8KB	922.1KB	+376.0B
`synthetics`	985.8KB	986.2KB	+376.0B
`transform`	634.3KB	634.7KB	+376.0B
`triggersActionsUi`	1.5MB	1.5MB	+670.0B
`uptime`	533.1KB	533.5KB	+376.0B
total			+5.4KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
`alerting`	52	51	-1

Page load bundle

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

id	before	after	diff
`observability`	94.6KB	94.6KB	-1.0B
`triggersActionsUi`	108.8KB	107.3KB	-1.5KB
total			-1.5KB

Unknown metric groups

API count

id	before	after	diff
`@kbn/alerting-types`	252	253	+1
`triggersActionsUi`	531	526	-5
total			-4

ESLint disabled in files

id	before	after	diff
`@kbn/response-ops-rules-apis`	-	2	+2

ESLint disabled line counts

id	before	after	diff
`@kbn/test-suites-xpack`	727	729	+2

Total ESLint disabled count

id	before	after	diff
`@kbn/response-ops-rules-apis`	-	2	+2
`@kbn/test-suites-xpack`	753	755	+2
total			+4

History

💚 Build #286134 succeeded e115542
💔 Build #286077 failed 027bfef
💔 Build #285998 failed 590f8df
💚 Build #285764 succeeded 270c282
💛 Build #284497 was flaky d69bef0
💚 Build #284420 succeeded 1865c02

maryam-saeidi

Code LGTM!

I tested having only logs or infra permissions, and it looked good.
One thing that I don't think is related to this PR was not showing "Anomaly detection rule" when we only have Logs or Infra permissions, but "useGetAvailableRulesWithDescriptions" returns this rule correctly.

Permission	Rules

Is this a known issue?

consulthys

LGT Stack Monitoring

cnasikas · 2025-03-26T08:55:39Z

One thing that I don't think is related to this PR was not showing "Anomaly detection rule" when we only have Logs or Infra permissions, but "useGetAvailableRulesWithDescriptions" returns this rule correctly.

To my understanding, you need to have ML permission for this rule type, correct?

kibanamachine · 2025-03-26T09:02:09Z

Starting backport for target branches: 8.x

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

kibanamachine · 2025-03-26T09:08:00Z

💔 All backports failed

Status	Branch	Result
❌	8.x	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 214187

Questions ?

Please refer to the Backport tool documentation

## Summary - Creates a `@kbn/response-ops-rules-apis` package, following the proposed structure for ResponseOps Management Experiences package. - Moves relevant rules API fetchers and react-query hooks to the new package. - Adds an internal variant of the `/api/alerting/rule_types` endpoint (`/internal/alerting/_rule_types`), that returns the same value as the public one + the newly added internal [`solution` field](elastic#212017), that we don't want to expose publicly. ## Verification steps 1. Create rules that fire alerts 2. Verify the usages of the moved/changed hooks, with limited privileges as well (i.e. only `Rules Settings` but not `Stack Rules`): 2.1. Stack management and Observability rules, rule details and alerts pages 2.2. Rules tab in the Connector editor flyout 2.3. Alerts table row actions (••• icon) 2.4. Tags filter in the rules list page 3. Using the DevTools, compare the response of the public and internal `rule_types` endpoins: ``` GET kbn:/api/alerting/rule_types GET kbn:/internal/alerting/_rule_types ``` Checking that the `solution` field is present only in the internal one ## References Closes elastic#213059 ### 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 --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 7aac590) # Conflicts: # .github/CODEOWNERS # x-pack/platform/plugins/shared/alerting/common/routes/rule/apis/list_types/schemas/v1.ts # x-pack/test/alerting_api_integration/security_and_spaces/group1/tests/alerting/rule_types_internal.ts # x-pack/test/alerting_api_integration/security_and_spaces/group5/tests/alerting/index.ts # x-pack/test/alerting_api_integration/spaces_only/tests/alerting/group1/get_rule_tags.ts

umbopepato · 2025-03-26T10:15:13Z

💚 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

# Backport This will backport the following commits from `main` to `8.x`: - [[ResponseOps][Rules] Create Rules APIs package (#214187)](#214187)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Alex Szabo <alex.szabo@elastic.co>

## Summary - Creates a `@kbn/response-ops-rules-apis` package, following the proposed structure for ResponseOps Management Experiences package. - Moves relevant rules API fetchers and react-query hooks to the new package. - Adds an internal variant of the `/api/alerting/rule_types` endpoint (`/internal/alerting/_rule_types`), that returns the same value as the public one + the newly added internal [`solution` field](elastic#212017), that we don't want to expose publicly. ## Verification steps 1. Create rules that fire alerts 2. Verify the usages of the moved/changed hooks, with limited privileges as well (i.e. only `Rules Settings` but not `Stack Rules`): 2.1. Stack management and Observability rules, rule details and alerts pages 2.2. Rules tab in the Connector editor flyout 2.3. Alerts table row actions (••• icon) 2.4. Tags filter in the rules list page 3. Using the DevTools, compare the response of the public and internal `rule_types` endpoins: ``` GET kbn:/api/alerting/rule_types GET kbn:/internal/alerting/_rule_types ``` Checking that the `solution` field is present only in the internal one ## References Closes elastic#213059 ### 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 --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

## Summary Implements the alerts filters form that will be used to pre-filter the alerts table embeddable. <img width="1004" alt="image" src="https://github.com/user-attachments/assets/b51ce051-40d2-42d0-a9c1-0fba3fd919af" /> > [!NOTE] > I'm using the terminology "form" to distinguish this from the alert filter _controls_ or other type of more KQL-bar-like filters. Other alternatives that came to mind were `alerts-boolean-filters-...` or `alerts-filters-builder`. <details> <summary> ## Implementation details </summary> ### Filters expression state I opted for a tree state representation of the form's boolean expression to accommodate potential future requirements such as more complex boolean expressions (negation, parenthesized subexpressions to manually control operators precedence): ```ts { operator: 'or', operands: [ { operator: 'or', operands: [ { type: 'ruleTags', value: ['tag-1'] }, { type: 'ruleTags', value: ['tag-2'] }, { operator: 'and', operands: [{ type: 'ruleTypes', value: ['type-1'] }, { type: 'ruleTypes', value: ['type-2'] }], }, ], }, { type: 'ruleTags', value: ['tag-3'] }, ], } ``` This state is saved in the embeddable panel state and represents the editor form. The embeddable alerts table wrapper component will then transform this to an actual ES query. To simplify interactions inside the form, an intermediate equivalent flattened state is used: ```ts [ { filter: { type: 'ruleTags', value: ['tag-1'] } }, { operator: 'or' }, { filter: { type: 'ruleTags', value: ['tag-2'] } }, { operator: 'or' }, { filter: { type: 'ruleTypes', value: ['type-1'] }}, { operator: 'and' }, { filter: { type: 'ruleTypes', value: ['type-2'] } }, { operator: 'or' }, { filter: { type: 'ruleTags', value: ['tag-3'] } }, ] ``` ### Filters model Each filter is described by an `AlertsFilterMetadata<T>` object, where `T` is the type of the filter value: ```tsx export const filterMetadata: AlertsFilterMetadata<string[]> = { id: 'ruleTags', displayName: RULE_TAGS_FILTER_LABEL, component: AlertsFilterByRuleTags, // Filter-specific empty check isEmpty: (value?: string[]) => !value?.length, // Conversion to ES query DSL toEsQuery: (value: string[]) => { return { terms: { [ALERT_RULE_TAGS]: value, }, }; }, }; ``` </details> ## Verification steps 1. Run Kibana with examples (`yarn start --run-examples`) 2. Create rules in different solutions with tags 3. Navigate to `/app/triggersActionsUiExample/alerts_filters_form` 4. Check that the solution selector options are coherent with the rule types the user can access 5. Select a solution 6. Build filters expressions, checking that the rule tags and rule types are coherent with the solution selection and the rules created previously 7. Repeat steps 3-6 with different roles: 7.1. having access to rule types from just one solution (in this case the solution selector shouldn't appear at all), 7.2. having access just to Observability and Stack but not Security (in this case the solution selector shouldn't appear at all), 8. Repeat steps 3-6 in the three serverless project types: ```shell $ yarn es serverless —ssl --projectType <es|oblt|security> $ yarn serverless-<es|oblt|security> --ssl --run-examples ``` (If the authentication fails when switching between project types, use a clean session) 8.1. ES project types should have access only to Stack rules (no selector) 8.2. Observability project types should have access only to Observability and Stack rules (no selector) 8.3. Security project types should have access only to Security and Stack rules (selector shows Stack instead of Observability) ## References Depends on #214187 Closes #213061 ### 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/src/platform/packages/shared/kbn-i18n/README.md) - [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: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>

## Summary Implements the alerts filters form that will be used to pre-filter the alerts table embeddable. <img width="1004" alt="image" src="https://github.com/user-attachments/assets/b51ce051-40d2-42d0-a9c1-0fba3fd919af" /> > [!NOTE] > I'm using the terminology "form" to distinguish this from the alert filter _controls_ or other type of more KQL-bar-like filters. Other alternatives that came to mind were `alerts-boolean-filters-...` or `alerts-filters-builder`. <details> <summary> ## Implementation details </summary> ### Filters expression state I opted for a tree state representation of the form's boolean expression to accommodate potential future requirements such as more complex boolean expressions (negation, parenthesized subexpressions to manually control operators precedence): ```ts { operator: 'or', operands: [ { operator: 'or', operands: [ { type: 'ruleTags', value: ['tag-1'] }, { type: 'ruleTags', value: ['tag-2'] }, { operator: 'and', operands: [{ type: 'ruleTypes', value: ['type-1'] }, { type: 'ruleTypes', value: ['type-2'] }], }, ], }, { type: 'ruleTags', value: ['tag-3'] }, ], } ``` This state is saved in the embeddable panel state and represents the editor form. The embeddable alerts table wrapper component will then transform this to an actual ES query. To simplify interactions inside the form, an intermediate equivalent flattened state is used: ```ts [ { filter: { type: 'ruleTags', value: ['tag-1'] } }, { operator: 'or' }, { filter: { type: 'ruleTags', value: ['tag-2'] } }, { operator: 'or' }, { filter: { type: 'ruleTypes', value: ['type-1'] }}, { operator: 'and' }, { filter: { type: 'ruleTypes', value: ['type-2'] } }, { operator: 'or' }, { filter: { type: 'ruleTags', value: ['tag-3'] } }, ] ``` ### Filters model Each filter is described by an `AlertsFilterMetadata<T>` object, where `T` is the type of the filter value: ```tsx export const filterMetadata: AlertsFilterMetadata<string[]> = { id: 'ruleTags', displayName: RULE_TAGS_FILTER_LABEL, component: AlertsFilterByRuleTags, // Filter-specific empty check isEmpty: (value?: string[]) => !value?.length, // Conversion to ES query DSL toEsQuery: (value: string[]) => { return { terms: { [ALERT_RULE_TAGS]: value, }, }; }, }; ``` </details> ## Verification steps 1. Run Kibana with examples (`yarn start --run-examples`) 2. Create rules in different solutions with tags 3. Navigate to `/app/triggersActionsUiExample/alerts_filters_form` 4. Check that the solution selector options are coherent with the rule types the user can access 5. Select a solution 6. Build filters expressions, checking that the rule tags and rule types are coherent with the solution selection and the rules created previously 7. Repeat steps 3-6 with different roles: 7.1. having access to rule types from just one solution (in this case the solution selector shouldn't appear at all), 7.2. having access just to Observability and Stack but not Security (in this case the solution selector shouldn't appear at all), 8. Repeat steps 3-6 in the three serverless project types: ```shell $ yarn es serverless —ssl --projectType <es|oblt|security> $ yarn serverless-<es|oblt|security> --ssl --run-examples ``` (If the authentication fails when switching between project types, use a clean session) 8.1. ES project types should have access only to Stack rules (no selector) 8.2. Observability project types should have access only to Observability and Stack rules (no selector) 8.3. Security project types should have access only to Security and Stack rules (selector shows Stack instead of Observability) ## References Depends on elastic#214187 Closes elastic#213061 ### 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/src/platform/packages/shared/kbn-i18n/README.md) - [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: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>

## Summary Implements the alerts filters form that will be used to pre-filter the alerts table embeddable. <img width="1004" alt="image" src="https://github.com/user-attachments/assets/b51ce051-40d2-42d0-a9c1-0fba3fd919af" /> > [!NOTE] > I'm using the terminology "form" to distinguish this from the alert filter _controls_ or other type of more KQL-bar-like filters. Other alternatives that came to mind were `alerts-boolean-filters-...` or `alerts-filters-builder`. <details> <summary> ## Implementation details </summary> ### Filters expression state I opted for a tree state representation of the form's boolean expression to accommodate potential future requirements such as more complex boolean expressions (negation, parenthesized subexpressions to manually control operators precedence): ```ts { operator: 'or', operands: [ { operator: 'or', operands: [ { type: 'ruleTags', value: ['tag-1'] }, { type: 'ruleTags', value: ['tag-2'] }, { operator: 'and', operands: [{ type: 'ruleTypes', value: ['type-1'] }, { type: 'ruleTypes', value: ['type-2'] }], }, ], }, { type: 'ruleTags', value: ['tag-3'] }, ], } ``` This state is saved in the embeddable panel state and represents the editor form. The embeddable alerts table wrapper component will then transform this to an actual ES query. To simplify interactions inside the form, an intermediate equivalent flattened state is used: ```ts [ { filter: { type: 'ruleTags', value: ['tag-1'] } }, { operator: 'or' }, { filter: { type: 'ruleTags', value: ['tag-2'] } }, { operator: 'or' }, { filter: { type: 'ruleTypes', value: ['type-1'] }}, { operator: 'and' }, { filter: { type: 'ruleTypes', value: ['type-2'] } }, { operator: 'or' }, { filter: { type: 'ruleTags', value: ['tag-3'] } }, ] ``` ### Filters model Each filter is described by an `AlertsFilterMetadata<T>` object, where `T` is the type of the filter value: ```tsx export const filterMetadata: AlertsFilterMetadata<string[]> = { id: 'ruleTags', displayName: RULE_TAGS_FILTER_LABEL, component: AlertsFilterByRuleTags, // Filter-specific empty check isEmpty: (value?: string[]) => !value?.length, // Conversion to ES query DSL toEsQuery: (value: string[]) => { return { terms: { [ALERT_RULE_TAGS]: value, }, }; }, }; ``` </details> ## Verification steps 1. Run Kibana with examples (`yarn start --run-examples`) 2. Create rules in different solutions with tags 3. Navigate to `/app/triggersActionsUiExample/alerts_filters_form` 4. Check that the solution selector options are coherent with the rule types the user can access 5. Select a solution 6. Build filters expressions, checking that the rule tags and rule types are coherent with the solution selection and the rules created previously 7. Repeat steps 3-6 with different roles: 7.1. having access to rule types from just one solution (in this case the solution selector shouldn't appear at all), 7.2. having access just to Observability and Stack but not Security (in this case the solution selector shouldn't appear at all), 8. Repeat steps 3-6 in the three serverless project types: ```shell $ yarn es serverless —ssl --projectType <es|oblt|security> $ yarn serverless-<es|oblt|security> --ssl --run-examples ``` (If the authentication fails when switching between project types, use a clean session) 8.1. ES project types should have access only to Stack rules (no selector) 8.2. Observability project types should have access only to Observability and Stack rules (no selector) 8.3. Security project types should have access only to Security and Stack rules (selector shows Stack instead of Observability) ## References Depends on elastic#214187 Closes elastic#213061 ### 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/src/platform/packages/shared/kbn-i18n/README.md) - [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: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com> (cherry picked from commit c44efc5) # Conflicts: # x-pack/examples/triggers_actions_ui_example/public/application.tsx

…218759) # Backport This will backport the following commits from `main` to `8.19`: - [[ResponseOps][Alerts] Implement alerts filters form (#214982)](#214982)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)

## Summary Implements the alerts filters form that will be used to pre-filter the alerts table embeddable. <img width="1004" alt="image" src="https://github.com/user-attachments/assets/b51ce051-40d2-42d0-a9c1-0fba3fd919af" /> > [!NOTE] > I'm using the terminology "form" to distinguish this from the alert filter _controls_ or other type of more KQL-bar-like filters. Other alternatives that came to mind were `alerts-boolean-filters-...` or `alerts-filters-builder`. <details> <summary> ## Implementation details </summary> ### Filters expression state I opted for a tree state representation of the form's boolean expression to accommodate potential future requirements such as more complex boolean expressions (negation, parenthesized subexpressions to manually control operators precedence): ```ts { operator: 'or', operands: [ { operator: 'or', operands: [ { type: 'ruleTags', value: ['tag-1'] }, { type: 'ruleTags', value: ['tag-2'] }, { operator: 'and', operands: [{ type: 'ruleTypes', value: ['type-1'] }, { type: 'ruleTypes', value: ['type-2'] }], }, ], }, { type: 'ruleTags', value: ['tag-3'] }, ], } ``` This state is saved in the embeddable panel state and represents the editor form. The embeddable alerts table wrapper component will then transform this to an actual ES query. To simplify interactions inside the form, an intermediate equivalent flattened state is used: ```ts [ { filter: { type: 'ruleTags', value: ['tag-1'] } }, { operator: 'or' }, { filter: { type: 'ruleTags', value: ['tag-2'] } }, { operator: 'or' }, { filter: { type: 'ruleTypes', value: ['type-1'] }}, { operator: 'and' }, { filter: { type: 'ruleTypes', value: ['type-2'] } }, { operator: 'or' }, { filter: { type: 'ruleTags', value: ['tag-3'] } }, ] ``` ### Filters model Each filter is described by an `AlertsFilterMetadata<T>` object, where `T` is the type of the filter value: ```tsx export const filterMetadata: AlertsFilterMetadata<string[]> = { id: 'ruleTags', displayName: RULE_TAGS_FILTER_LABEL, component: AlertsFilterByRuleTags, // Filter-specific empty check isEmpty: (value?: string[]) => !value?.length, // Conversion to ES query DSL toEsQuery: (value: string[]) => { return { terms: { [ALERT_RULE_TAGS]: value, }, }; }, }; ``` </details> ## Verification steps 1. Run Kibana with examples (`yarn start --run-examples`) 2. Create rules in different solutions with tags 3. Navigate to `/app/triggersActionsUiExample/alerts_filters_form` 4. Check that the solution selector options are coherent with the rule types the user can access 5. Select a solution 6. Build filters expressions, checking that the rule tags and rule types are coherent with the solution selection and the rules created previously 7. Repeat steps 3-6 with different roles: 7.1. having access to rule types from just one solution (in this case the solution selector shouldn't appear at all), 7.2. having access just to Observability and Stack but not Security (in this case the solution selector shouldn't appear at all), 8. Repeat steps 3-6 in the three serverless project types: ```shell $ yarn es serverless —ssl --projectType <es|oblt|security> $ yarn serverless-<es|oblt|security> --ssl --run-examples ``` (If the authentication fails when switching between project types, use a clean session) 8.1. ES project types should have access only to Stack rules (no selector) 8.2. Observability project types should have access only to Observability and Stack rules (no selector) 8.3. Security project types should have access only to Security and Stack rules (selector shows Stack instead of Observability) ## References Depends on elastic#214187 Closes elastic#213061 ### 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/src/platform/packages/shared/kbn-i18n/README.md) - [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: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>

umbopepato force-pushed the 213059-response-ops-rules-apis-package branch 5 times, most recently from e67c495 to 63a821c Compare March 13, 2025 14:29

umbopepato added release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Platform ResponseOps team (formerly the Cases and Alerting teams) t// backport:version Backport to applied version labels v9.1.0 v8.19.0 labels Mar 13, 2025

umbopepato force-pushed the 213059-response-ops-rules-apis-package branch from 63a821c to 8251343 Compare March 13, 2025 16:30

umbopepato commented Mar 13, 2025

View reviewed changes

umbopepato and others added 11 commits March 14, 2025 10:32

Move get rule tags API to @kbn/response-ops-rules-apis

0be26ba

Add internal rule types route, fetcher and query hook

edcde44

Fix translations

67b20ac

Fix type error

08b7383

Fix tests

9cf0f85

Add last shared rule APIs to package

e05ef91

[CI] Auto-commit changed files from 'node scripts/generate codeowners'

e1e55f4

Fix translations

c2a425f

Fix tests

706a8be

Fix tests

9e77938

Fix RuleDefinition props instability

d9d4c47

kibanamachine and others added 4 commits March 21, 2025 11:30

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

027bfef

Fix integration test

f04eb76

Merge branch 'main' of github.com:elastic/kibana into 213059-response…

859f879

…-ops-rules-apis-package

Fix unit test

e115542

umbopepato mentioned this pull request Mar 24, 2025

[ResponseOps][Alerts] Implement alerts filters form #214982

Merged

2 tasks

umbopepato and others added 3 commits March 24, 2025 14:14

Merge branch 'main' into 213059-response-ops-rules-apis-package

c933c02

Remove unnecessary mock

6a3b06d

Merge branch 'main' of github.com:elastic/kibana into 213059-response…

74ed203

…-ops-rules-apis-package

jcger approved these changes Mar 25, 2025

View reviewed changes

maryam-saeidi self-requested a review March 25, 2025 09:25

maryam-saeidi approved these changes Mar 25, 2025

View reviewed changes

consulthys approved these changes Mar 25, 2025

View reviewed changes

cnasikas approved these changes Mar 26, 2025

View reviewed changes

umbopepato merged commit 7aac590 into elastic:main Mar 26, 2025
10 checks passed

umbopepato mentioned this pull request Mar 26, 2025

[8.x] [ResponseOps][Rules] Create Rules APIs package (#214187) #216006

Merged

kibanamachine mentioned this pull request Mar 26, 2025

[fix] Fix lint errors introduced parallel to arming the rule #216047

Merged


		export const BASE_ALERTING_API_PATH = '/api/alerting';

		export const queryKeys = {

Conversation

umbopepato commented Mar 12, 2025 • edited by kibanamachine Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Verification steps

References

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

umbopepato Mar 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

umbopepato commented Mar 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elasticmachine commented Mar 24, 2025

💚 Build Succeeded

Metrics [docs]

Module Count

Public APIs missing comments

Async chunks

Public APIs missing exports

Page load bundle

API count

ESLint disabled in files

ESLint disabled line counts

Total ESLint disabled count

History

Uh oh!

maryam-saeidi left a comment

Choose a reason for hiding this comment

Uh oh!

consulthys left a comment

Choose a reason for hiding this comment

Uh oh!

cnasikas commented Mar 26, 2025

Uh oh!

Uh oh!

kibanamachine commented Mar 26, 2025

Uh oh!

kibanamachine commented Mar 26, 2025

💔 All backports failed

Manual backport

Questions ?

Uh oh!

umbopepato commented Mar 26, 2025

💚 All backports created successfully

Questions ?

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

umbopepato commented Mar 12, 2025 •

edited by kibanamachine

Loading

umbopepato Mar 13, 2025 •

edited

Loading

umbopepato commented Mar 24, 2025 •

edited

Loading