[ResponseOps][Alerts] Implement alerts filters form

[umbopepato]

Summary

Implements the alerts filters form that will be used to pre-filter the alerts table embeddable.

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.

Implementation details

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):

{
  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:

[
  { 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:

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,
      },
    };
  },
};

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:

   $ 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

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[umbopepato]

This ensures that the form is initialized with an initially empty "Filter by" selector

[jcger]

nit: this comment here could be a comment in code for future us

[js-jankisalvi]

Great work! looks really good 🎉
Could you please add an integration test or functional test to check different roles and users to verify solutions and rule types privileges?

I have a user with `security` and `stack rules` privileges. However the solution shows `observability`. Shouldn't it be security and stack like serverless?

security_and_stack.mov

security_and_stack_permissions.mov

[umbopepato]

Great work! looks really good 🎉

Thanks for taking a look Janki! 😊

Could you please add an integration test or functional test to check different roles and users to verify solutions and rule types privileges?

I was hoping to test the complete creation flow with the Dashboard panel as well 🙂

I have a user with security and stack rules privileges. However the solution shows observability. Shouldn't it be security and stack like serverless?

Yes, that's normal since in non-serverless envs when enabling the Stack rules privilege you also get access to multi-consumer rule types, one of which is categorized under observability. That shouldn't be a problem since it's just a label we show, but it includes both solutions. That is to say: the privileges of the users are always honored

[cnasikas]

Thanks for your patience and with addressing my comments!

[cnasikas]

nit: Do not forget to remove this.

[umbopepato]

Done ✅

[cnasikas]

Suggested change

	expect(isFilter(filter as Parameters<typeof isFilter>[0])).toBeFalsy();
	// @ts-expect-error: testing empty values
	expect(isFilter(filter)).toBeFalsy();

[umbopepato]

Done ✅

[cnasikas]

I was referring to const filter = useMemo(() => {. Any idea on that?

[cnasikas]

A pseudo example of how it can be done without any useEffects or call of onSolutionChange.

// top-level component
const { data: ruleTypes, isLoading, isError } = useGetInternalRuleTypesQuery({ http });

if (isLoading) {
   return null;
}

return <AlertsFilterFormWraper ruleTypes={ruleTypes}> // name tbd


// AlertsFilterFormWraper
// ruleTypes always available as the component will render after the fetch
const AlertsFilterFormWraper = ({ ruleTypes }) => {

const availableSolutions = useMemo(() => getAvailableSolutions(ruleTypes), [ruleTypes]);

const [selectedSolution, setSelectedSolution] = useState(availableSolutions.length === 1 ? availableSolutions[0].value : undefined) // or whatever default we want.

availableSolutions.length > 1 && <AlertsSolutionSelector availableSolutions={availableSolutions} selectedSolution={selectedSolution} onSolutionChange={setSolution}>

}

It is very similar to what you have in the sandbox with some tweaks. We can do it on the final PR.

[azasypkin]

Changes in package.json LGTM

[kibanamachine]

Starting backport for target branches: 8.19

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

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 108db58

Metrics [docs]

Async chunks

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

id	before	after	diff
triggersActionsUi	1.4MB	1.4MB	+40.0B

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
@kbn/response-ops-alerts-filters-form	-	1	+1

Total ESLint disabled count

id	before	after	diff
@kbn/response-ops-alerts-filters-form	-	1	+1

History

• 💚 Build #294048 succeeded 7aa5569
• 💚 Build #293089 succeeded 1990bab
• 💚 Build #292722 succeeded 8786ed0
• 💛 Build #292290 was flaky 64945e6
• 💛 Build #292229 was flaky 6991785
• 💛 Build #291957 was flaky 0138a34

[kibanamachine]

💔 All backports failed

Status	Branch	Result
❌	8.19	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 214982

Questions ?

Please refer to the Backport tool documentation

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create automatically backports add a backport:* label or prevent reminders by adding the backport:skip label.
You can also create backports manually by running node scripts/backport --pr 214982 locally

[umbopepato]

💚 All backports created successfully

Status	Branch	Result
✅	8.19

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

Questions ?

Please refer to the Backport tool documentation