We would like to allow users the ability to delete their alerts based on certain configuration conditions. To do this, we would like to create a new task type that is scheduled ad-hoc using an HTTP API. This ability will be controlled by a new rules settings subfeature privilege.

This issue covers the task-related changes required for the alert deletion MVP

Rules settings

We should add a new sub-feature privilege to the rules settings feature privilege to control access to the alert deletion strategy:

When users have all access to this setting, they will be able to:

• enable/disable the conditions for alert deletion
• modify the configuration for alert deletion
• view the last time the cleanup task was performed
• view how many alerts currently match the deletion conditions
• manually kick off a cleanup task (which will only apply to the current space).

When users have read access to this setting, they will be able to:

• view the current configuration
• view the last time the cleanup task was performed.
• view how many alerts currently match the deletion conditions

The setting should encompass the following configurations:

• delete active alerts created more than N days ago (this option can be completely disabled)
• delete inactive alerts that were recovered/closed/untracked more than N days ago (this option can be completely disabled)
• whether the setting should apply to observability/stack/security rules (similar to how maintenance windows work)

Task

We should create a new task type that can be scheduled ad-hoc. When it runs, the task will query for all alert deletion rules settings (there are potentially one per space) and build ES requests necessary to fulfill the deletion.

Active alert was created more than N days ago

If this condition is configured, the task will delete alerts in the specified space that match the query:
(event.kind: "open" OR event.kind: "active") AND kibana.alert.start < now - N days AND NOT kibana.alert.end:*.

Inactive alert was recovered, closed or untracked more than N days ago

If this condition is enabled, the task will delete alerts in the specified space that match the query
(event.kind: "close" AND @timestamp < now - N days) OR (kibana.alert.workflow_status:"closed" AND kibana.alert.workflow_status_updated_at < now - N days) OR (kibana.alert.status:"untracked" AND kibana.alert.end < now - N days)

Because ad-hoc tasks are deleted after they run and do not persist state, we should write an event log entry to save the time the task was run, the number of alerts deleted and the success or failure of the run.

Definition of done

• New rules settings introduced
• New task type created
• Unit and functional tests created