* [Alerts][License] Define minimum license required for each alert type (#84997)
* Define minimum license required for each alert type
* fixed typechecks
* fixed tests
* fixed tests
* fixed due to comments
* fixed due to comments
* removed file
* removed casting to LicenseType
* [Alerts][License] Add license checks to alerts HTTP APIs and execution (#85223)
* [Alerts][License] Add license checks to alerts HTTP APIs and execution
* fixed typechecks
* resolved conflicts
* resolved conflicts
* added router tests
* fixed typechecks
* added license check support for alert task running
* fixed typechecks
* added integration tests
* fixed due to comments
* fixed due to comments
* fixed tests
* fixed typechecks
* [Alerting UI][License] Disable alert types in UI when the license doesn't support it. (#85496)
* [Alerting UI][License] Disable alert types in UI when the license doesn't support it.
* fixed typechecks
* added licensing for alert list and details page
* fixed multy select menu
* fixed due to comments
* fixed due to comments
* fixed due to comments
* fixed typechecks
* fixed license error message
* fixed license error message
* fixed typechecks
* fixed license error message
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* plugged Task Manager lifecycle into status reactively
* fixed tests
* Revert "fixed tests"
This reverts commit e9f2cd05bd.
* made action group fields optional
* revert deletion
* again
* extracted action type for mto its own component
* extracted more sections of the action form to their own components
* updated icon
* added docs
* fixed always firing alert
* fixed export of components
* fixed react warning
* Adding flag for notifying on state change
* Updating logic in task runner
* Starting to update tests
* Adding tests
* Fixing types check
* Tests and types
* Tests
* Tests
* Tests
* Tests
* Tests
* Renaming field to a more descriptive name. Adding migrations
* Renaming field to a more descriptive name. Adding migrations
* Fixing tests
* Type check and tests
* Moving schedule and notify interval to bottom of flyout. Implementing dropdown from mockup in new component
* Changing boolean flag to enum type and updating in triggers_actions_ui
* Changing boolean flag to enum type and updating in alerts plugin
* Fixing types check
* Fixing monitoring jest tests
* Changing last references to old variable names
* Moving form inputs back to the top
* Renaming to alert_notify_when
* Updating functional tests
* Adding new functional test for notifyWhen onActionGroupChange
* Updating wording
* Incorporating action subgroups into logic
* PR fixes
* Updating functional test
* Fixing types check
* Changing default throttle interval to hour
* Fixing types check
Co-authored-by: Gidi Meir Morris <github@gidi.io>
This PR introduces a new concept of an _Action Subgroup_ (naming is open for discussion) which can be used by an Alert Type when scheduling actions.
An Action Subgroup can be dynamically specified, unlike Action Groups which have to be specified on the AlertType definition.
When scheduling actions, and AlertType can specify an _Action Subgroup_ along side the scheduled _Action Group_, which denotes that the alert instance falls into some kind of narrower grouping in the action group.
* Adding disabled action groups to action type definition
* Adding tests
* Adding tests
* renamed Resolved to Recovered
* fixed missing import
* fixed buggy default message behaviour
* added missing test
* fixed typing
* fixed resolved in tests
* allows alert types to specify their own custom recovery group name
* removed unnecesery field on always fires
* allows alert types to specify their own custom recovery group
* fixed mock alert types throughout unit tests
* fixed typing issues
* reduce repetition of mock data
* fixed alert type list test
* support legacy event log alert recovery syntax
* added doc
* removed unneeded change in jira
* correct callback name in siem
* renamed resolved to recovered
* fixed mistaken rename
* Moving to alert plugin
* Updating tests
* elvated default params to alert concern instead of actions concern
* made default params optional
* Adding test
* Moving where default action params are retrieved
* Revert "Moving where default action params are retrieved"
This reverts commit 76e7608229.
* Moving where default action params are retrieved
* Cleanup
* Fixing test
* PR fixes
Co-authored-by: Gidi Meir Morris <github@gidi.io>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
In this PR we introduce a new `recoveryActionGroup` field on AlertTypes which allows an implementor to specify a custom action group which the framework will use when an alert instance goes from _active_ to _inactive_.
By default all alert types will use the existing `RecoveryActionGroup`, but when `recoveryActionGroup` is specified, this group is used instead.
This is applied across the UI, event log and underlying object model, rather than just being a label change.
To support this we also introduced the `alertActionGroupName` message variable which is the human readable version of existing `alertActionGroup` variable.
Reapplies the #84123 PR:
This PR changes the default term from “Resolved” to “Recovered”, as it fits most use cases and we feel users are most likely to understand its meaning across domains.
This PR changes the default term from “Resolved” to “Recovered”, as it fits most use cases and we feel users are most likely to understand its meaning across domains.
This PR adds two components to aid in creating a uniform UI for specifying the conditions for Action Groups:
1. `AlertConditions`: A component that generates a container which renders custom component for each Action Group which has had its _conditions_ specified.
2. `AlertConditionsGroup`: A component that provides a unified container for the Action Group with its name and a button for resetting its condition.
This can be used by any Alert Type to easily create the UI for adding action groups with whichever UI is specific to their component.
* Added ability to fire actions when an alert instance is resolved
* Fixed due to comments
* Fixed merge issue
* Fixed tests and added skip for muted resolve
* added test for muted alert
* Fixed due to comments
* Fixed registry error message
* Fixed jest test
* Implemented Alerting health status pusher by using task manager and status pooler for Kibana status plugins 'kibanahost/api/status'
* Exposed health task registration to alerts plugin
* Fixed type error
* Extended health API endpoint with info about decryption failures, added correct health task implementation
* adjusted query
* Tested locally and got it working as expected, fixed tests and type check
* Added unit tests
* Changed AlertExecutionStatusErrorReasons to be enum
* Uppercase the enum
* Replaced string values to enum
* Fixed types
* Extended AlertsClient with getHealth method
* added return type to healthStatus$
* Added configurable health check interval and timestamps
* Extended update core status interval to 5mins
* Fixed failing tests
* Registered alerts config
* Fixed date for ok health state
* fixed jest test
* fixed task state
* Fixed due to comments, moved getHealth to a plugin level
* fixed type checks
* Added sorting to the latest Ok state last update
* adjusted error queries
* Fixed jest tests
* removed unused
* fixed type check
* Adding action group id to event log. Showing action group as part of status in alert details view
* Simplifying getting action group id
* Cleanup
* Adding unit tests
* Updating functional tests
* Updating test
* Fix types check
* Updating test
* PR fixes
* PR fixes
* wip
* wip
* Adding aggregation option to find function and using those results in UI
* Requesting aggregations from client instead of hard-coding in route
* alert_api test
* i18n fix
* Adding functional test
* Adding unit test for filters
* Splitting into two API endpoints
* Fixing test
* Fixing test
* Adding comment
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
resolves https://github.com/elastic/kibana/issues/51099
This formalizes the concept of "alert status", in terms of it's execution, with
some new fields in the alert saved object and types used with the alert client
and http APIs.
These fields are read-only from the client point-of-view; they are provided in
the alert structures, but are only updated by the alerting framework itself.
The values will be updated after each run of the alert type executor.
The data is added to the alert as the `executionStatus` field, with the
following shape:
```ts
interface AlertExecutionStatus {
status: 'ok' | 'active' | 'error' | 'pending' | 'unknown';
lastExecutionDate: Date;
error?: {
reason: 'read' | 'decrypt' | 'execute' | 'unknown';
message: string;
};
}
```
* Initial work
* Expand generic support to alert instances
* Convert index threshold to use generics
* Make fixture alert types use generics
* Make alert instance related types use unknown
* Fix typecheck failures
* Cleanup + add instance generic support to registry.get API
* Shallow clone
* Rename some TS variables
* Fix failing api integration tests
* Change code for easier review and keep more history
* Fix
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR adds _Role Based Access-Control_ to the Alerting framework & Actions feature using Kibana Feature Controls, addressing most of the Meta issue: https://github.com/elastic/kibana/issues/43994
This also closes https://github.com/elastic/kibana/issues/62438
This PR includes the following:
1. Adds `alerting` specific Security Actions (not to be confused with Alerting Actions) to the `security` plugin which allows us to assign alerting specific privileges to users of other plugins using the `features` plugin.
2. Removes the security wrapper from the savedObjectsClient in AlertsClient and instead plugs in the new AlertsAuthorization which performs the privilege checks on each api call made to the AlertsClient.
3. Adds privileges in each plugin that is already using the Alerting Framework which mirror (as closely as possible) the existing api-level tag-based privileges and plugs them into the AlertsClient.
4. Adds feature granted privileges arounds Actions (by relying on Saved Object privileges under the hood) and plugs them into the ActionsClient
5. Removes the legacy api-level tag-based privilege system from both the Alerts and Action HTTP APIs
