Skip to content

[8.19] [ResponseOps][Alerts] Implement alerts filters form (#214982)#218759

Merged
umbopepato merged 1 commit intoelastic:8.19from
umbopepato:backport/8.19/pr-214982
Apr 22, 2025
Merged

[8.19] [ResponseOps][Alerts] Implement alerts filters form (#214982)#218759
umbopepato merged 1 commit intoelastic:8.19from
umbopepato:backport/8.19/pr-214982

Conversation

@umbopepato
Copy link
Member

Backport

This will backport the following commits from main to 8.19:

Questions ?

Please refer to the Backport tool documentation

## 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
@umbopepato umbopepato added the backport This PR is a backport of another PR label Apr 22, 2025
@umbopepato umbopepato enabled auto-merge (squash) April 22, 2025 07:08
@umbopepato umbopepato merged commit 5a4cc35 into elastic:8.19 Apr 22, 2025
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport This PR is a backport of another PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants