Commit graph

861 commits

Author SHA1 Message Date
Antonio
6645f27122
[8.16] [ResponseOps][MW] Use date format from settings in MW UI (#211576) (#214545)
# Backport

This will backport the following commits from `main` to `8.16`:
- [[ResponseOps][MW] Use date format from settings in MW UI
(#211576)](https://github.com/elastic/kibana/pull/211576)

<!--- Backport version: 9.6.4 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)

<!--BACKPORT
[{"author":{"name":"Antonio","email":"antonio.coelho@elastic.co"},"sourceCommit":{"committedDate":"2025-03-07T12:45:48Z","message":"[ResponseOps][MW]
Use date format from settings in MW UI (#211576)\n\nCloses #199315\n\n##
Summary\n\nThis PR changes the Maintenance Window UI to respect the date
format\nconfigured in Kibana's advanced settings.\n\n3 places needed
changing:\n- Maintenance window list.\n- Maintenance window creation
page.\n- Event popover in the maintenance window list(for recurring
MWs).","sha":"2ead636ebd3d8dc911dd870111c8e016035169c1","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","backport:version","v9.1.0","v8.19.0"],"title":"[ResponseOps][MW]
Use date format from settings in MW
UI","number":211576,"url":"https://github.com/elastic/kibana/pull/211576","mergeCommit":{"message":"[ResponseOps][MW]
Use date format from settings in MW UI (#211576)\n\nCloses #199315\n\n##
Summary\n\nThis PR changes the Maintenance Window UI to respect the date
format\nconfigured in Kibana's advanced settings.\n\n3 places needed
changing:\n- Maintenance window list.\n- Maintenance window creation
page.\n- Event popover in the maintenance window list(for recurring
MWs).","sha":"2ead636ebd3d8dc911dd870111c8e016035169c1"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/211576","number":211576,"mergeCommit":{"message":"[ResponseOps][MW]
Use date format from settings in MW UI (#211576)\n\nCloses #199315\n\n##
Summary\n\nThis PR changes the Maintenance Window UI to respect the date
format\nconfigured in Kibana's advanced settings.\n\n3 places needed
changing:\n- Maintenance window list.\n- Maintenance window creation
page.\n- Event popover in the maintenance window list(for recurring
MWs).","sha":"2ead636ebd3d8dc911dd870111c8e016035169c1"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/214438","number":214438,"state":"MERGED","mergeCommit":{"sha":"e74dfe03009087cf65fce16bf43c4053120aff46","message":"[8.x]
[ResponseOps][MW] Use date format from settings in MW UI (#211576)
(#214438)\n\n# Backport\n\nThis will backport the following commits from
`main` to `8.x`:\n- [[ResponseOps][MW] Use date format from settings in
MW
UI\n(#211576)](https://github.com/elastic/kibana/pull/211576)\n\n<!---
Backport version: 9.6.6 -->\n\n### Questions ?\nPlease refer to the
[Backport
tool\ndocumentation](https://github.com/sorenlouv/backport)\n\n<!--BACKPORT\n[{\"author\":{\"name\":\"Antonio\",\"email\":\"antonio.coelho@elastic.co\"},\"sourceCommit\":{\"committedDate\":\"2025-03-07T12:45:48Z\",\"message\":\"[ResponseOps][MW]\nUse
date format from settings in MW UI (#211576)\\n\\nCloses
#199315\\n\\n##\nSummary\\n\\nThis PR changes the Maintenance Window UI
to respect the date\nformat\\nconfigured in Kibana's advanced
settings.\\n\\n3 places needed\nchanging:\\n- Maintenance window
list.\\n- Maintenance window creation\npage.\\n- Event popover in the
maintenance window list(for
recurring\nMWs).\",\"sha\":\"2ead636ebd3d8dc911dd870111c8e016035169c1\",\"branchLabelMapping\":{\"^v9.1.0$\":\"main\",\"^v8.19.0$\":\"8.x\",\"^v(\\\\d+).(\\\\d+).\\\\d+$\":\"$1.$2\"}},\"sourcePullRequest\":{\"labels\":[\"release_note:skip\",\"Team:ResponseOps\",\"backport\nmissing\",\"backport:version\",\"v9.1.0\",\"v8.19.0\"],\"title\":\"[ResponseOps][MW]\nUse
date format from settings in
MW\nUI\",\"number\":211576,\"url\":\"https://github.com/elastic/kibana/pull/211576\",\"mergeCommit\":{\"message\":\"[ResponseOps][MW]\nUse
date format from settings in MW UI (#211576)\\n\\nCloses
#199315\\n\\n##\nSummary\\n\\nThis PR changes the Maintenance Window UI
to respect the date\nformat\\nconfigured in Kibana's advanced
settings.\\n\\n3 places needed\nchanging:\\n- Maintenance window
list.\\n- Maintenance window creation\npage.\\n- Event popover in the
maintenance window list(for
recurring\nMWs).\",\"sha\":\"2ead636ebd3d8dc911dd870111c8e016035169c1\"}},\"sourceBranch\":\"main\",\"suggestedTargetBranches\":[\"8.x\"],\"targetPullRequestStates\":[{\"branch\":\"main\",\"label\":\"v9.1.0\",\"branchLabelMappingKey\":\"^v9.1.0$\",\"isSourceBranch\":true,\"state\":\"MERGED\",\"url\":\"https://github.com/elastic/kibana/pull/211576\",\"number\":211576,\"mergeCommit\":{\"message\":\"[ResponseOps][MW]\nUse
date format from settings in MW UI (#211576)\\n\\nCloses
#199315\\n\\n##\nSummary\\n\\nThis PR changes the Maintenance Window UI
to respect the date\nformat\\nconfigured in Kibana's advanced
settings.\\n\\n3 places needed\nchanging:\\n- Maintenance window
list.\\n- Maintenance window creation\npage.\\n- Event popover in the
maintenance window list(for
recurring\nMWs).\",\"sha\":\"2ead636ebd3d8dc911dd870111c8e016035169c1\"}},{\"branch\":\"8.x\",\"label\":\"v8.19.0\",\"branchLabelMappingKey\":\"^v8.19.0$\",\"isSourceBranch\":false,\"state\":\"NOT_CREATED\"}]}]\nBACKPORT-->\n\n---------\n\nCo-authored-by:
kibanamachine <42973632+kibanamachine@users.noreply.github.com>"}}]}]
BACKPORT-->

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
2025-03-14 15:10:06 +02:00
Christos Nasikas
f81c0edb27
[8.16] [ResponseOps][Rules] Validate timezone in rule routes (#201508) (#208300)
# Backport

This will backport the following commits from `main` to `8.16`:
- [[ResponseOps][Rules] Validate timezone in rule routes
(#201508)](https://github.com/elastic/kibana/pull/201508)

<!--- Backport version: 9.6.4 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)

<!--BACKPORT [{"author":{"name":"Christos
Nasikas","email":"christos.nasikas@elastic.co"},"sourceCommit":{"committedDate":"2025-01-24T17:46:24Z","message":"[ResponseOps][Rules]
Validate timezone in rule routes (#201508)\n\n## Summary\r\n\r\nThis PR
adds validation only for internal routes that use the
`rRule`\r\nschema.\r\n\r\n## Testing\r\n\r\n1. Create a rule in
main.\r\n2. Snooze the rule by using the API as\r\n\r\n```\r\nPOST
/internal/alerting/rule/<ruleId>/_snooze\r\n{\r\n \"snooze_schedule\":
{\r\n \"id\": \"e58e2340-dba6-454c-8308-b2ca66a7cf7b\",\r\n
\"duration\": 86400000,\r\n \"rRule\": {\r\n \"dtstart\":
\"2024-09-04T09:27:37.011Z\",\r\n \"tzid\": \"invalid\",\r\n \"freq\":
2,\r\n \"interval\": 1,\r\n \"byweekday\": [\r\n \"invalid\"\r\n ]\r\n
}\r\n }\r\n}\r\n```\r\n\r\n4. Go to the rules page and verify that the
rules are not loaded.\r\n5. Switch to my PR.\r\n6. Go to the rules page
and verify that the rules load.\r\n\r\n### Checklist\r\n\r\n- [x] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"9a3fc89629e1a6cec2f5200bb75099fcab866701","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","Feature:Alerting/RulesFramework","backport:prev-major","v8.18.0","v8.16.4","v8.17.2"],"title":"[ResponseOps][Rules]
Validate timezone in rule
routes","number":201508,"url":"https://github.com/elastic/kibana/pull/201508","mergeCommit":{"message":"[ResponseOps][Rules]
Validate timezone in rule routes (#201508)\n\n## Summary\r\n\r\nThis PR
adds validation only for internal routes that use the
`rRule`\r\nschema.\r\n\r\n## Testing\r\n\r\n1. Create a rule in
main.\r\n2. Snooze the rule by using the API as\r\n\r\n```\r\nPOST
/internal/alerting/rule/<ruleId>/_snooze\r\n{\r\n \"snooze_schedule\":
{\r\n \"id\": \"e58e2340-dba6-454c-8308-b2ca66a7cf7b\",\r\n
\"duration\": 86400000,\r\n \"rRule\": {\r\n \"dtstart\":
\"2024-09-04T09:27:37.011Z\",\r\n \"tzid\": \"invalid\",\r\n \"freq\":
2,\r\n \"interval\": 1,\r\n \"byweekday\": [\r\n \"invalid\"\r\n ]\r\n
}\r\n }\r\n}\r\n```\r\n\r\n4. Go to the rules page and verify that the
rules are not loaded.\r\n5. Switch to my PR.\r\n6. Go to the rules page
and verify that the rules load.\r\n\r\n### Checklist\r\n\r\n- [x] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"9a3fc89629e1a6cec2f5200bb75099fcab866701"}},"sourceBranch":"main","suggestedTargetBranches":["8.16","8.17"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/201508","number":201508,"mergeCommit":{"message":"[ResponseOps][Rules]
Validate timezone in rule routes (#201508)\n\n## Summary\r\n\r\nThis PR
adds validation only for internal routes that use the
`rRule`\r\nschema.\r\n\r\n## Testing\r\n\r\n1. Create a rule in
main.\r\n2. Snooze the rule by using the API as\r\n\r\n```\r\nPOST
/internal/alerting/rule/<ruleId>/_snooze\r\n{\r\n \"snooze_schedule\":
{\r\n \"id\": \"e58e2340-dba6-454c-8308-b2ca66a7cf7b\",\r\n
\"duration\": 86400000,\r\n \"rRule\": {\r\n \"dtstart\":
\"2024-09-04T09:27:37.011Z\",\r\n \"tzid\": \"invalid\",\r\n \"freq\":
2,\r\n \"interval\": 1,\r\n \"byweekday\": [\r\n \"invalid\"\r\n ]\r\n
}\r\n }\r\n}\r\n```\r\n\r\n4. Go to the rules page and verify that the
rules are not loaded.\r\n5. Switch to my PR.\r\n6. Go to the rules page
and verify that the rules load.\r\n\r\n### Checklist\r\n\r\n- [x] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"9a3fc89629e1a6cec2f5200bb75099fcab866701"}},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/208252","number":208252,"state":"OPEN"},{"branch":"8.16","label":"v8.16.4","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.17","label":"v8.17.2","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
2025-01-28 09:01:00 +01:00
Antonio
33063e343a
[8.16] [Response Ops] Fix maintenance window custom schedule create and update error (#192649) (#208334)
# Backport

This will backport the following commits from `main` to `8.16`:
- [[Response Ops] Fix maintenance window custom schedule create and
update error (#192649)](https://github.com/elastic/kibana/pull/192649)

<!--- Backport version: 9.6.4 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)

<!--BACKPORT [{"author":{"name":"Jiawei
Wu","email":"74562234+JiaweiWu@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-09-16T23:52:00Z","message":"[Response
Ops] Fix maintenance window custom schedule create and update error
(#192649)\n\n## Summary\r\nFixes a bug where the backend would throw an
error if we tried to create\r\nor update a maintenance window with a
custom schedule. This was due to\r\nthe `form-lib` converting everything
`frequency`, `interval`, and\r\n`customFrequency` field to a string and
our logic assumed it was a\r\nnumber so the `===` comparisons were
failing.\r\n\r\n### How to test:\r\n1. Navigate to the create
maintenance window form\r\n2. Attempt to create a maintenance window
with a custom schedule\r\n3. Assert the maintenance window was created
successfully\r\n4. Attempt to edit the maintenance window with a
different custom\r\nschedule\r\n5. Assert the maintenance window was
edited successfully \r\n\r\nFixes:
https://github.com/elastic/kibana/issues/192601\r\n\r\n---------\r\n\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"134b81572c4234e9c813aa5ed5dda286a99ffc32","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:skip","backport:skip","Team:ResponseOps","v9.0.0","v8.16.0"],"title":"[Response
Ops] Fix maintenance window custom schedule create and update
error","number":192649,"url":"https://github.com/elastic/kibana/pull/192649","mergeCommit":{"message":"[Response
Ops] Fix maintenance window custom schedule create and update error
(#192649)\n\n## Summary\r\nFixes a bug where the backend would throw an
error if we tried to create\r\nor update a maintenance window with a
custom schedule. This was due to\r\nthe `form-lib` converting everything
`frequency`, `interval`, and\r\n`customFrequency` field to a string and
our logic assumed it was a\r\nnumber so the `===` comparisons were
failing.\r\n\r\n### How to test:\r\n1. Navigate to the create
maintenance window form\r\n2. Attempt to create a maintenance window
with a custom schedule\r\n3. Assert the maintenance window was created
successfully\r\n4. Attempt to edit the maintenance window with a
different custom\r\nschedule\r\n5. Assert the maintenance window was
edited successfully \r\n\r\nFixes:
https://github.com/elastic/kibana/issues/192601\r\n\r\n---------\r\n\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"134b81572c4234e9c813aa5ed5dda286a99ffc32"}},"sourceBranch":"main","suggestedTargetBranches":["8.16"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/192649","number":192649,"mergeCommit":{"message":"[Response
Ops] Fix maintenance window custom schedule create and update error
(#192649)\n\n## Summary\r\nFixes a bug where the backend would throw an
error if we tried to create\r\nor update a maintenance window with a
custom schedule. This was due to\r\nthe `form-lib` converting everything
`frequency`, `interval`, and\r\n`customFrequency` field to a string and
our logic assumed it was a\r\nnumber so the `===` comparisons were
failing.\r\n\r\n### How to test:\r\n1. Navigate to the create
maintenance window form\r\n2. Attempt to create a maintenance window
with a custom schedule\r\n3. Assert the maintenance window was created
successfully\r\n4. Attempt to edit the maintenance window with a
different custom\r\nschedule\r\n5. Assert the maintenance window was
edited successfully \r\n\r\nFixes:
https://github.com/elastic/kibana/issues/192601\r\n\r\n---------\r\n\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"134b81572c4234e9c813aa5ed5dda286a99ffc32"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Jiawei Wu <74562234+JiaweiWu@users.noreply.github.com>
2025-01-27 16:26:42 +01:00
Antonio
5a6b240dfd
[8.16] [ResponseOps][MW] Fix bug when creating repeating Maintenance Window (#207084) (#208313)
# Backport

This will backport the following commits from `main` to `8.16`:
- [[ResponseOps][MW] Fix bug when creating repeating Maintenance Window
(#207084)](https://github.com/elastic/kibana/pull/207084)

<!--- Backport version: 9.6.4 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)

<!--BACKPORT
[{"author":{"name":"Antonio","email":"antonio.coelho@elastic.co"},"sourceCommit":{"committedDate":"2025-01-24T11:40:25Z","message":"[ResponseOps][MW]
Fix bug when creating repeating Maintenance Window (#207084)\n\nCloses
#198774\r\n\r\n## Summary\r\n\r\n- There was a bug when submitting
`rrule` with a `byweekday` I fixed\r\nthat validation to use a more
inclusive regex. `byweekday` can be the\r\nexpected `MO`, `TU`, etc but
also `-1FR` or `+3SA` where the number\r\ncorresponds to the week in a
month.\r\n- The model version for the maintenance window was incorrect
so when\r\nsaving the SO the validation was failing. I fixed that and
now we are\r\nallowed to save `number[]` as expected.\r\n- I removed
some duplicated code and we now use the `rrule` schema from\r\nthe
`common`
folder","sha":"0df78e629b429f6007f559aca339b4323b71e4c0","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-major","v8.18.0"],"title":"[ResponseOps][MW]
Fix bug when creating repeating Maintenance
Window","number":207084,"url":"https://github.com/elastic/kibana/pull/207084","mergeCommit":{"message":"[ResponseOps][MW]
Fix bug when creating repeating Maintenance Window (#207084)\n\nCloses
#198774\r\n\r\n## Summary\r\n\r\n- There was a bug when submitting
`rrule` with a `byweekday` I fixed\r\nthat validation to use a more
inclusive regex. `byweekday` can be the\r\nexpected `MO`, `TU`, etc but
also `-1FR` or `+3SA` where the number\r\ncorresponds to the week in a
month.\r\n- The model version for the maintenance window was incorrect
so when\r\nsaving the SO the validation was failing. I fixed that and
now we are\r\nallowed to save `number[]` as expected.\r\n- I removed
some duplicated code and we now use the `rrule` schema from\r\nthe
`common`
folder","sha":"0df78e629b429f6007f559aca339b4323b71e4c0"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/207084","number":207084,"mergeCommit":{"message":"[ResponseOps][MW]
Fix bug when creating repeating Maintenance Window (#207084)\n\nCloses
#198774\r\n\r\n## Summary\r\n\r\n- There was a bug when submitting
`rrule` with a `byweekday` I fixed\r\nthat validation to use a more
inclusive regex. `byweekday` can be the\r\nexpected `MO`, `TU`, etc but
also `-1FR` or `+3SA` where the number\r\ncorresponds to the week in a
month.\r\n- The model version for the maintenance window was incorrect
so when\r\nsaving the SO the validation was failing. I fixed that and
now we are\r\nallowed to save `number[]` as expected.\r\n- I removed
some duplicated code and we now use the `rrule` schema from\r\nthe
`common`
folder","sha":"0df78e629b429f6007f559aca339b4323b71e4c0"}},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/208181","number":208181,"state":"MERGED","mergeCommit":{"sha":"8759f0286675744937e4ed8f5ad4880e35f6547e","message":"[8.x]
[ResponseOps][MW] Fix bug when creating repeating Maintenance Window
(#207084) (#208181)\n\n# Backport\r\n\r\nThis will backport the
following commits from `main` to `8.x`:\r\n- [[ResponseOps][MW] Fix bug
when creating repeating Maintenance
Window\r\n(#207084)](https://github.com/elastic/kibana/pull/207084)\r\n\r\n<!---
Backport version: 9.6.4 -->\r\n\r\n### Questions ?\r\nPlease refer to
the [Backport
tool\r\ndocumentation](https://github.com/sorenlouv/backport)\r\n\r\n<!--BACKPORT\r\n[{\"author\":{\"name\":\"Antonio\",\"email\":\"antonio.coelho@elastic.co\"},\"sourceCommit\":{\"committedDate\":\"2025-01-24T11:40:25Z\",\"message\":\"[ResponseOps][MW]\r\nFix
bug when creating repeating Maintenance Window
(#207084)\\n\\nCloses\r\n#198774\\r\\n\\r\\n## Summary\\r\\n\\r\\n-
There was a bug when submitting\r\n`rrule` with a `byweekday` I
fixed\\r\\nthat validation to use a more\r\ninclusive regex. `byweekday`
can be the\\r\\nexpected `MO`, `TU`, etc but\r\nalso `-1FR` or `+3SA`
where the number\\r\\ncorresponds to the week in a\r\nmonth.\\r\\n- The
model version for the maintenance window was incorrect\r\nso
when\\r\\nsaving the SO the validation was failing. I fixed that
and\r\nnow we are\\r\\nallowed to save `number[]` as expected.\\r\\n- I
removed\r\nsome duplicated code and we now use the `rrule` schema
from\\r\\nthe\r\n`common`\r\nfolder\",\"sha\":\"0df78e629b429f6007f559aca339b4323b71e4c0\",\"branchLabelMapping\":{\"^v9.0.0$\":\"main\",\"^v8.18.0$\":\"8.x\",\"^v(\\\\d+).(\\\\d+).\\\\d+$\":\"$1.$2\"}},\"sourcePullRequest\":{\"labels\":[\"Feature:Alerting\",\"release_note:skip\",\"Team:ResponseOps\",\"v9.0.0\",\"backport:prev-major\"],\"title\":\"[ResponseOps][MW]\r\nFix
bug when creating repeating
Maintenance\r\nWindow\",\"number\":207084,\"url\":\"https://github.com/elastic/kibana/pull/207084\",\"mergeCommit\":{\"message\":\"[ResponseOps][MW]\r\nFix
bug when creating repeating Maintenance Window
(#207084)\\n\\nCloses\r\n#198774\\r\\n\\r\\n## Summary\\r\\n\\r\\n-
There was a bug when submitting\r\n`rrule` with a `byweekday` I
fixed\\r\\nthat validation to use a more\r\ninclusive regex. `byweekday`
can be the\\r\\nexpected `MO`, `TU`, etc but\r\nalso `-1FR` or `+3SA`
where the number\\r\\ncorresponds to the week in a\r\nmonth.\\r\\n- The
model version for the maintenance window was incorrect\r\nso
when\\r\\nsaving the SO the validation was failing. I fixed that
and\r\nnow we are\\r\\nallowed to save `number[]` as expected.\\r\\n- I
removed\r\nsome duplicated code and we now use the `rrule` schema
from\\r\\nthe\r\n`common`\r\nfolder\",\"sha\":\"0df78e629b429f6007f559aca339b4323b71e4c0\"}},\"sourceBranch\":\"main\",\"suggestedTargetBranches\":[],\"targetPullRequestStates\":[{\"branch\":\"main\",\"label\":\"v9.0.0\",\"branchLabelMappingKey\":\"^v9.0.0$\",\"isSourceBranch\":true,\"state\":\"MERGED\",\"url\":\"https://github.com/elastic/kibana/pull/207084\",\"number\":207084,\"mergeCommit\":{\"message\":\"[ResponseOps][MW]\r\nFix
bug when creating repeating Maintenance Window
(#207084)\\n\\nCloses\r\n#198774\\r\\n\\r\\n## Summary\\r\\n\\r\\n-
There was a bug when submitting\r\n`rrule` with a `byweekday` I
fixed\\r\\nthat validation to use a more\r\ninclusive regex. `byweekday`
can be the\\r\\nexpected `MO`, `TU`, etc but\r\nalso `-1FR` or `+3SA`
where the number\\r\\ncorresponds to the week in a\r\nmonth.\\r\\n- The
model version for the maintenance window was incorrect\r\nso
when\\r\\nsaving the SO the validation was failing. I fixed that
and\r\nnow we are\\r\\nallowed to save `number[]` as expected.\\r\\n- I
removed\r\nsome duplicated code and we now use the `rrule` schema
from\\r\\nthe\r\n`common`
folder\",\"sha\":\"0df78e629b429f6007f559aca339b4323b71e4c0\"}}]}]\r\nBACKPORT-->"}},{"url":"https://github.com/elastic/kibana/pull/208312","number":208312,"branch":"8.17","state":"OPEN"}]}]
BACKPORT-->
2025-01-27 12:25:56 +01:00
Mike Côté
98100987d6
[8.16] [ResponseOps] [Alerting] Handle invalid RRule params and prevent infinite looping (#205650) (#205831)
# Backport

This will backport the following commits from `main` to `8.16`:
- [[ResponseOps] [Alerting] Handle invalid RRule params and prevent
infinite looping
(#205650)](https://github.com/elastic/kibana/pull/205650)

<!--- Backport version: 8.9.8 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Zacqary Adam
Xeper","email":"Zacqary@users.noreply.github.com"},"sourceCommit":{"committedDate":"2025-01-07T19:32:43Z","message":"[ResponseOps]
[Alerting] Handle invalid RRule params and prevent infinite looping
(#205650)\n\n## Summary\r\n\r\nCloses
https://github.com/elastic/kibana/issues/205558\r\n\r\nUpdates the RRule
library to correctly handle some scenarios with\r\ninvalid parameters
that would either cause it to return strange\r\nrecurrence data or to
infinitely loop. Specifically:\r\n\r\n- On `RRule` object creation,
removes and ignores any `bymonth`,\r\n`bymonthday`, `byweekday`, or
`byyearday` value that's out of bounds,\r\ne.g. less than 0 or greater
than the number of possible months, days,\r\nweekdays, etc.\r\n-
Successfully ignores cases of `BYMONTH=2, BYMONTHDAY=30`
(February\r\n30th), an input that's complicated to invalidate but still
won't ever\r\noccur\r\n\r\nAllowing these values to go unhandled led to
unpredictable behavior. The\r\nRRule library uses Moment.js to compare
dates, but Moment.js months,\r\ndays, and other values generally start
at `0` while RRule values start\r\nat `1`. That led to several
circumstances where we passed Moment.js a\r\nvalue of `-1`, which
Moment.js interpreted as moving to the\r\n***previous*** year, month, or
other period of time.\r\n\r\nAt worst, this could cause an infinite loop
because the RRule library\r\nwas constantly iterating through the wrong
year, never reaching the date\r\nit was supposed to end on.\r\n\r\nIn
addition to making the RRule library more able to handle these
cases,\r\nthis PR also gives it a hard 100,000 iteration limit to
prevent any\r\npossible infinite loops we've missed.\r\n\r\nLastly, the
Snooze Schedule APIs also come with additional validation
to\r\nhopefully prevent out of bounds dates from ever being
set.\r\n\r\n### Checklist\r\n\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Janki Salvi
<117571355+js-jankisalvi@users.noreply.github.com>\r\nCo-authored-by:
Janki Salvi <jankigaurav.salvi@elastic.co>\r\nCo-authored-by: adcoelho
<antonio.coelho@elastic.co>","sha":"b30210929be0824f684f0b7d9d13bc936c1cbd22","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","Team:ResponseOps","v9.0.0","Feature:Alerting/RulesFramework","backport:version","v8.18.0","v8.16.3","v8.17.1"],"number":205650,"url":"https://github.com/elastic/kibana/pull/205650","mergeCommit":{"message":"[ResponseOps]
[Alerting] Handle invalid RRule params and prevent infinite looping
(#205650)\n\n## Summary\r\n\r\nCloses
https://github.com/elastic/kibana/issues/205558\r\n\r\nUpdates the RRule
library to correctly handle some scenarios with\r\ninvalid parameters
that would either cause it to return strange\r\nrecurrence data or to
infinitely loop. Specifically:\r\n\r\n- On `RRule` object creation,
removes and ignores any `bymonth`,\r\n`bymonthday`, `byweekday`, or
`byyearday` value that's out of bounds,\r\ne.g. less than 0 or greater
than the number of possible months, days,\r\nweekdays, etc.\r\n-
Successfully ignores cases of `BYMONTH=2, BYMONTHDAY=30`
(February\r\n30th), an input that's complicated to invalidate but still
won't ever\r\noccur\r\n\r\nAllowing these values to go unhandled led to
unpredictable behavior. The\r\nRRule library uses Moment.js to compare
dates, but Moment.js months,\r\ndays, and other values generally start
at `0` while RRule values start\r\nat `1`. That led to several
circumstances where we passed Moment.js a\r\nvalue of `-1`, which
Moment.js interpreted as moving to the\r\n***previous*** year, month, or
other period of time.\r\n\r\nAt worst, this could cause an infinite loop
because the RRule library\r\nwas constantly iterating through the wrong
year, never reaching the date\r\nit was supposed to end on.\r\n\r\nIn
addition to making the RRule library more able to handle these
cases,\r\nthis PR also gives it a hard 100,000 iteration limit to
prevent any\r\npossible infinite loops we've missed.\r\n\r\nLastly, the
Snooze Schedule APIs also come with additional validation
to\r\nhopefully prevent out of bounds dates from ever being
set.\r\n\r\n### Checklist\r\n\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Janki Salvi
<117571355+js-jankisalvi@users.noreply.github.com>\r\nCo-authored-by:
Janki Salvi <jankigaurav.salvi@elastic.co>\r\nCo-authored-by: adcoelho
<antonio.coelho@elastic.co>","sha":"b30210929be0824f684f0b7d9d13bc936c1cbd22"}},"sourceBranch":"main","suggestedTargetBranches":["8.16","8.17"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/205650","number":205650,"mergeCommit":{"message":"[ResponseOps]
[Alerting] Handle invalid RRule params and prevent infinite looping
(#205650)\n\n## Summary\r\n\r\nCloses
https://github.com/elastic/kibana/issues/205558\r\n\r\nUpdates the RRule
library to correctly handle some scenarios with\r\ninvalid parameters
that would either cause it to return strange\r\nrecurrence data or to
infinitely loop. Specifically:\r\n\r\n- On `RRule` object creation,
removes and ignores any `bymonth`,\r\n`bymonthday`, `byweekday`, or
`byyearday` value that's out of bounds,\r\ne.g. less than 0 or greater
than the number of possible months, days,\r\nweekdays, etc.\r\n-
Successfully ignores cases of `BYMONTH=2, BYMONTHDAY=30`
(February\r\n30th), an input that's complicated to invalidate but still
won't ever\r\noccur\r\n\r\nAllowing these values to go unhandled led to
unpredictable behavior. The\r\nRRule library uses Moment.js to compare
dates, but Moment.js months,\r\ndays, and other values generally start
at `0` while RRule values start\r\nat `1`. That led to several
circumstances where we passed Moment.js a\r\nvalue of `-1`, which
Moment.js interpreted as moving to the\r\n***previous*** year, month, or
other period of time.\r\n\r\nAt worst, this could cause an infinite loop
because the RRule library\r\nwas constantly iterating through the wrong
year, never reaching the date\r\nit was supposed to end on.\r\n\r\nIn
addition to making the RRule library more able to handle these
cases,\r\nthis PR also gives it a hard 100,000 iteration limit to
prevent any\r\npossible infinite loops we've missed.\r\n\r\nLastly, the
Snooze Schedule APIs also come with additional validation
to\r\nhopefully prevent out of bounds dates from ever being
set.\r\n\r\n### Checklist\r\n\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Janki Salvi
<117571355+js-jankisalvi@users.noreply.github.com>\r\nCo-authored-by:
Janki Salvi <jankigaurav.salvi@elastic.co>\r\nCo-authored-by: adcoelho
<antonio.coelho@elastic.co>","sha":"b30210929be0824f684f0b7d9d13bc936c1cbd22"}},{"branch":"8.x","label":"v8.18.0","labelRegex":"^v8.18.0$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/205803","number":205803,"state":"MERGED","mergeCommit":{"sha":"a02fcb232faed2f385ce9b97fbdb323ccbf8ca45","message":"[8.x]
[ResponseOps] [Alerting] Handle invalid RRule params and prevent
infinite looping (#205650) (#205803)\n\n# Backport\n\nThis will backport
the following commits from `main` to `8.x`:\n- [[ResponseOps] [Alerting]
Handle invalid RRule params and prevent\ninfinite
looping\n(#205650)](https://github.com/elastic/kibana/pull/205650)\n\n<!---
Backport version: 9.4.3 -->\n\n### Questions ?\nPlease refer to the
[Backport
tool\ndocumentation](https://github.com/sqren/backport)\n\n<!--BACKPORT
[{\"author\":{\"name\":\"Zacqary
Adam\nXeper\",\"email\":\"Zacqary@users.noreply.github.com\"},\"sourceCommit\":{\"committedDate\":\"2025-01-07T19:32:43Z\",\"message\":\"[ResponseOps]\n[Alerting]
Handle invalid RRule params and prevent infinite
looping\n(#205650)\\n\\n##
Summary\\r\\n\\r\\nCloses\nhttps://github.com/elastic/kibana/issues/205558\\r\\n\\r\\nUpdates
the RRule\nlibrary to correctly handle some scenarios with\\r\\ninvalid
parameters\nthat would either cause it to return strange\\r\\nrecurrence
data or to\ninfinitely loop. Specifically:\\r\\n\\r\\n- On `RRule`
object creation,\nremoves and ignores any `bymonth`,\\r\\n`bymonthday`,
`byweekday`, or\n`byyearday` value that's out of bounds,\\r\\ne.g. less
than 0 or greater\nthan the number of possible months,
days,\\r\\nweekdays, etc.\\r\\n-\nSuccessfully ignores cases of
`BYMONTH=2, BYMONTHDAY=30`\n(February\\r\\n30th), an input that's
complicated to invalidate but still\nwon't
ever\\r\\noccur\\r\\n\\r\\nAllowing these values to go unhandled led
to\nunpredictable behavior. The\\r\\nRRule library uses Moment.js to
compare\ndates, but Moment.js months,\\r\\ndays, and other values
generally start\nat `0` while RRule values start\\r\\nat `1`. That led
to several\ncircumstances where we passed Moment.js a\\r\\nvalue of
`-1`, which\nMoment.js interpreted as moving to the\\r\\n***previous***
year, month, or\nother period of time.\\r\\n\\r\\nAt worst, this could
cause an infinite loop\nbecause the RRule library\\r\\nwas constantly
iterating through the wrong\nyear, never reaching the date\\r\\nit was
supposed to end on.\\r\\n\\r\\nIn\naddition to making the RRule library
more able to handle these\ncases,\\r\\nthis PR also gives it a hard
100,000 iteration limit to\nprevent any\\r\\npossible infinite loops
we've missed.\\r\\n\\r\\nLastly, the\nSnooze Schedule APIs also come
with additional validation\nto\\r\\nhopefully prevent out of bounds
dates from ever being\nset.\\r\\n\\r\\n### Checklist\\r\\n\\r\\n- [x]
[Unit
or\nfunctional\\r\\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\\r\\nwere\nupdated
or added to match the most
common\nscenarios\\r\\n\\r\\n---------\\r\\n\\r\\nCo-authored-by:
kibanamachine\n<42973632+kibanamachine@users.noreply.github.com>\\r\\nCo-authored-by:\nJanki
Salvi\n<117571355+js-jankisalvi@users.noreply.github.com>\\r\\nCo-authored-by:\nJanki
Salvi <jankigaurav.salvi@elastic.co>\\r\\nCo-authored-by:
adcoelho\n<antonio.coelho@elastic.co>\",\"sha\":\"b30210929be0824f684f0b7d9d13bc936c1cbd22\",\"branchLabelMapping\":{\"^v9.0.0$\":\"main\",\"^v8.18.0$\":\"8.x\",\"^v(\\\\d+).(\\\\d+).\\\\d+$\":\"$1.$2\"}},\"sourcePullRequest\":{\"labels\":[\"release_note:fix\",\"Team:ResponseOps\",\"v9.0.0\",\"Feature:Alerting/RulesFramework\",\"backport:version\",\"v8.18.0\",\"v8.16.3\",\"v8.17.1\"],\"title\":\"[ResponseOps]\n[Alerting]
Handle invalid RRule params and prevent
infinite\nlooping\",\"number\":205650,\"url\":\"https://github.com/elastic/kibana/pull/205650\",\"mergeCommit\":{\"message\":\"[ResponseOps]\n[Alerting]
Handle invalid RRule params and prevent infinite
looping\n(#205650)\\n\\n##
Summary\\r\\n\\r\\nCloses\nhttps://github.com/elastic/kibana/issues/205558\\r\\n\\r\\nUpdates
the RRule\nlibrary to correctly handle some scenarios with\\r\\ninvalid
parameters\nthat would either cause it to return strange\\r\\nrecurrence
data or to\ninfinitely loop. Specifically:\\r\\n\\r\\n- On `RRule`
object creation,\nremoves and ignores any `bymonth`,\\r\\n`bymonthday`,
`byweekday`, or\n`byyearday` value that's out of bounds,\\r\\ne.g. less
than 0 or greater\nthan the number of possible months,
days,\\r\\nweekdays, etc.\\r\\n-\nSuccessfully ignores cases of
`BYMONTH=2, BYMONTHDAY=30`\n(February\\r\\n30th), an input that's
complicated to invalidate but still\nwon't
ever\\r\\noccur\\r\\n\\r\\nAllowing these values to go unhandled led
to\nunpredictable behavior. The\\r\\nRRule library uses Moment.js to
compare\ndates, but Moment.js months,\\r\\ndays, and other values
generally start\nat `0` while RRule values start\\r\\nat `1`. That led
to several\ncircumstances where we passed Moment.js a\\r\\nvalue of
`-1`, which\nMoment.js interpreted as moving to the\\r\\n***previous***
year, month, or\nother period of time.\\r\\n\\r\\nAt worst, this could
cause an infinite loop\nbecause the RRule library\\r\\nwas constantly
iterating through the wrong\nyear, never reaching the date\\r\\nit was
supposed to end on.\\r\\n\\r\\nIn\naddition to making the RRule library
more able to handle these\ncases,\\r\\nthis PR also gives it a hard
100,000 iteration limit to\nprevent any\\r\\npossible infinite loops
we've missed.\\r\\n\\r\\nLastly, the\nSnooze Schedule APIs also come
with additional validation\nto\\r\\nhopefully prevent out of bounds
dates from ever being\nset.\\r\\n\\r\\n### Checklist\\r\\n\\r\\n- [x]
[Unit
or\nfunctional\\r\\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\\r\\nwere\nupdated
or added to match the most
common\nscenarios\\r\\n\\r\\n---------\\r\\n\\r\\nCo-authored-by:
kibanamachine\n<42973632+kibanamachine@users.noreply.github.com>\\r\\nCo-authored-by:\nJanki
Salvi\n<117571355+js-jankisalvi@users.noreply.github.com>\\r\\nCo-authored-by:\nJanki
Salvi <jankigaurav.salvi@elastic.co>\\r\\nCo-authored-by:
adcoelho\n<antonio.coelho@elastic.co>\",\"sha\":\"b30210929be0824f684f0b7d9d13bc936c1cbd22\"}},\"sourceBranch\":\"main\",\"suggestedTargetBranches\":[\"8.x\",\"8.16\",\"8.17\"],\"targetPullRequestStates\":[{\"branch\":\"main\",\"label\":\"v9.0.0\",\"branchLabelMappingKey\":\"^v9.0.0$\",\"isSourceBranch\":true,\"state\":\"MERGED\",\"url\":\"https://github.com/elastic/kibana/pull/205650\",\"number\":205650,\"mergeCommit\":{\"message\":\"[ResponseOps]\n[Alerting]
Handle invalid RRule params and prevent infinite
looping\n(#205650)\\n\\n##
Summary\\r\\n\\r\\nCloses\nhttps://github.com/elastic/kibana/issues/205558\\r\\n\\r\\nUpdates
the RRule\nlibrary to correctly handle some scenarios with\\r\\ninvalid
parameters\nthat would either cause it to return strange\\r\\nrecurrence
data or to\ninfinitely loop. Specifically:\\r\\n\\r\\n- On `RRule`
object creation,\nremoves and ignores any `bymonth`,\\r\\n`bymonthday`,
`byweekday`, or\n`byyearday` value that's out of bounds,\\r\\ne.g. less
than 0 or greater\nthan the number of possible months,
days,\\r\\nweekdays, etc.\\r\\n-\nSuccessfully ignores cases of
`BYMONTH=2, BYMONTHDAY=30`\n(February\\r\\n30th), an input that's
complicated to invalidate but still\nwon't
ever\\r\\noccur\\r\\n\\r\\nAllowing these values to go unhandled led
to\nunpredictable behavior. The\\r\\nRRule library uses Moment.js to
compare\ndates, but Moment.js months,\\r\\ndays, and other values
generally start\nat `0` while RRule values start\\r\\nat `1`. That led
to several\ncircumstances where we passed Moment.js a\\r\\nvalue of
`-1`, which\nMoment.js interpreted as moving to the\\r\\n***previous***
year, month, or\nother period of time.\\r\\n\\r\\nAt worst, this could
cause an infinite loop\nbecause the RRule library\\r\\nwas constantly
iterating through the wrong\nyear, never reaching the date\\r\\nit was
supposed to end on.\\r\\n\\r\\nIn\naddition to making the RRule library
more able to handle these\ncases,\\r\\nthis PR also gives it a hard
100,000 iteration limit to\nprevent any\\r\\npossible infinite loops
we've missed.\\r\\n\\r\\nLastly, the\nSnooze Schedule APIs also come
with additional validation\nto\\r\\nhopefully prevent out of bounds
dates from ever being\nset.\\r\\n\\r\\n### Checklist\\r\\n\\r\\n- [x]
[Unit
or\nfunctional\\r\\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\\r\\nwere\nupdated
or added to match the most
common\nscenarios\\r\\n\\r\\n---------\\r\\n\\r\\nCo-authored-by:
kibanamachine\n<42973632+kibanamachine@users.noreply.github.com>\\r\\nCo-authored-by:\nJanki
Salvi\n<117571355+js-jankisalvi@users.noreply.github.com>\\r\\nCo-authored-by:\nJanki
Salvi <jankigaurav.salvi@elastic.co>\\r\\nCo-authored-by:
adcoelho\n<antonio.coelho@elastic.co>\",\"sha\":\"b30210929be0824f684f0b7d9d13bc936c1cbd22\"}},{\"branch\":\"8.x\",\"label\":\"v8.18.0\",\"branchLabelMappingKey\":\"^v8.18.0$\",\"isSourceBranch\":false,\"state\":\"NOT_CREATED\"},{\"branch\":\"8.16\",\"label\":\"v8.16.3\",\"branchLabelMappingKey\":\"^v(\\\\d+).(\\\\d+).\\\\d+$\",\"isSourceBranch\":false,\"state\":\"NOT_CREATED\"},{\"branch\":\"8.17\",\"label\":\"v8.17.1\",\"branchLabelMappingKey\":\"^v(\\\\d+).(\\\\d+).\\\\d+$\",\"isSourceBranch\":false,\"state\":\"NOT_CREATED\"}]}]\nBACKPORT-->\n\nCo-authored-by:
Zacqary Adam Xeper
<Zacqary@users.noreply.github.com>"}},{"branch":"8.16","label":"v8.16.3","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.17","label":"v8.17.1","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

---------

Co-authored-by: Zacqary Adam Xeper <Zacqary@users.noreply.github.com>
2025-01-08 03:44:44 +00:00
Devin W. Hurley
d2dd29eb85
[8.16] [Security Solution] Fixes exception item comment validation on newline chars \n (#202063) (#203709)
# Backport

This will backport the following commits from `main` to `8.16`:
- [[Security Solution] Fixes exception item comment validation on
newline chars `\n`
(#202063)](https://github.com/elastic/kibana/pull/202063)

<!--- Backport version: 8.9.8 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Devin W.
Hurley","email":"devin.hurley@elastic.co"},"sourceCommit":{"committedDate":"2024-12-10T22:19:32Z","message":"[Security
Solution] Fixes exception item comment validation on newline chars `\\n`
(#202063)\n\n## Summary\r\n\r\nFixes:
https://github.com/elastic/kibana/issues/201820\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"35aeac104359eae81a233d0b8a9acaa97119d006","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","review","release_note:fix","v9.0.0","Team:Detections
and Resp","Feature:Rule
Exceptions","backport:version","v8.18.0","v8.16.2","v8.17.1"],"number":202063,"url":"https://github.com/elastic/kibana/pull/202063","mergeCommit":{"message":"[Security
Solution] Fixes exception item comment validation on newline chars `\\n`
(#202063)\n\n## Summary\r\n\r\nFixes:
https://github.com/elastic/kibana/issues/201820\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"35aeac104359eae81a233d0b8a9acaa97119d006"}},"sourceBranch":"main","suggestedTargetBranches":["8.x","8.16","8.17"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/202063","number":202063,"mergeCommit":{"message":"[Security
Solution] Fixes exception item comment validation on newline chars `\\n`
(#202063)\n\n## Summary\r\n\r\nFixes:
https://github.com/elastic/kibana/issues/201820\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"35aeac104359eae81a233d0b8a9acaa97119d006"}},{"branch":"8.x","label":"v8.18.0","labelRegex":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.16","label":"v8.16.2","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.17","label":"v8.17.1","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
2024-12-10 23:33:06 -05:00
Mike Côté
7ed9a663bc
[8.16] Set refresh according to stateful vs stateless when indexing alert documents (#201209) (#202222)
# Backport

This will backport the following commits from `main` to `8.16`:
- [Set refresh according to stateful vs stateless when indexing alert
documents (#201209)](https://github.com/elastic/kibana/pull/201209)

<!--- Backport version: 8.9.8 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Mike
Côté","email":"mikecote@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-11-28T17:10:56Z","message":"Set
refresh according to stateful vs stateless when indexing alert documents
(#201209)\n\nIn this PR, I'm making the change so when Kibana is running
with\r\nElasticsearch stateful we set refresh to `wait_for` (instead of
`true`)\r\nso we are not putting too much pressure on the Elasticsearch
indices\r\nwhen under load.\r\n\r\n## To verify\r\n\r\nVery using the
Cloud deployment and Serverless project created from
this\r\nPR\r\n\r\n1. Create an always firing ES Query rule\r\n2. Create
an always firing security detection rule w/ alert suppression\r\n3.
Verify the ECH cluster logs and observe `*** Refresh value
when\r\nindexing alerts: wait_for` and `*** Rule registry - refresh
value when\r\nindexing alerts: wait_for` messages\r\n4. Verify the
serverless project logs on QA overview and observe `***\r\nRefresh value
when indexing alerts: true` and `*** Rule registry -\r\nrefresh value
when indexing alerts: true` messages\r\n\r\n## To-Do\r\n\r\n- [x] Revert
commit\r\n7c19b458e6\r\nthat
was added for testing purposes\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"a4cb330af2d414e383d75efce526513171098ece","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Team:ResponseOps","v9.0.0","ci:project-deploy-observability","Team:obs-ux-management","backport:version","v8.17.0","v8.16.1"],"number":201209,"url":"https://github.com/elastic/kibana/pull/201209","mergeCommit":{"message":"Set
refresh according to stateful vs stateless when indexing alert documents
(#201209)\n\nIn this PR, I'm making the change so when Kibana is running
with\r\nElasticsearch stateful we set refresh to `wait_for` (instead of
`true`)\r\nso we are not putting too much pressure on the Elasticsearch
indices\r\nwhen under load.\r\n\r\n## To verify\r\n\r\nVery using the
Cloud deployment and Serverless project created from
this\r\nPR\r\n\r\n1. Create an always firing ES Query rule\r\n2. Create
an always firing security detection rule w/ alert suppression\r\n3.
Verify the ECH cluster logs and observe `*** Refresh value
when\r\nindexing alerts: wait_for` and `*** Rule registry - refresh
value when\r\nindexing alerts: wait_for` messages\r\n4. Verify the
serverless project logs on QA overview and observe `***\r\nRefresh value
when indexing alerts: true` and `*** Rule registry -\r\nrefresh value
when indexing alerts: true` messages\r\n\r\n## To-Do\r\n\r\n- [x] Revert
commit\r\n7c19b458e6\r\nthat
was added for testing purposes\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"a4cb330af2d414e383d75efce526513171098ece"}},"sourceBranch":"main","suggestedTargetBranches":["8.17","8.16"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/201209","number":201209,"mergeCommit":{"message":"Set
refresh according to stateful vs stateless when indexing alert documents
(#201209)\n\nIn this PR, I'm making the change so when Kibana is running
with\r\nElasticsearch stateful we set refresh to `wait_for` (instead of
`true`)\r\nso we are not putting too much pressure on the Elasticsearch
indices\r\nwhen under load.\r\n\r\n## To verify\r\n\r\nVery using the
Cloud deployment and Serverless project created from
this\r\nPR\r\n\r\n1. Create an always firing ES Query rule\r\n2. Create
an always firing security detection rule w/ alert suppression\r\n3.
Verify the ECH cluster logs and observe `*** Refresh value
when\r\nindexing alerts: wait_for` and `*** Rule registry - refresh
value when\r\nindexing alerts: wait_for` messages\r\n4. Verify the
serverless project logs on QA overview and observe `***\r\nRefresh value
when indexing alerts: true` and `*** Rule registry -\r\nrefresh value
when indexing alerts: true` messages\r\n\r\n## To-Do\r\n\r\n- [x] Revert
commit\r\n7c19b458e6\r\nthat
was added for testing purposes\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"a4cb330af2d414e383d75efce526513171098ece"}},{"branch":"8.17","label":"v8.17.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.16","label":"v8.16.1","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
2024-11-29 07:45:23 -06:00
Lisa Cawley
2f05849f65
[8.16] [OpenAPI][DOCS] Add descriptions for alerting rule flapping properties (#200112) (#200221)
# Backport

This will backport the following commits from `main` to `8.16`:
- [[OpenAPI][DOCS] Add descriptions for alerting rule flapping
properties (#200112)](https://github.com/elastic/kibana/pull/200112)

<!--- Backport version: 8.9.8 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Lisa
Cawley","email":"lcawley@elastic.co"},"sourceCommit":{"committedDate":"2024-11-14T15:54:51Z","message":"[OpenAPI][DOCS]
Add descriptions for alerting rule flapping properties
(#200112)","sha":"50f0016cd7b01eabc280aca4131f843ff305231d","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Team:ResponseOps","v9.0.0","backport:version","v8.17.0","v8.16.1"],"number":200112,"url":"https://github.com/elastic/kibana/pull/200112","mergeCommit":{"message":"[OpenAPI][DOCS]
Add descriptions for alerting rule flapping properties
(#200112)","sha":"50f0016cd7b01eabc280aca4131f843ff305231d"}},"sourceBranch":"main","suggestedTargetBranches":["8.x","8.16"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/200112","number":200112,"mergeCommit":{"message":"[OpenAPI][DOCS]
Add descriptions for alerting rule flapping properties
(#200112)","sha":"50f0016cd7b01eabc280aca4131f843ff305231d"}},{"branch":"8.x","label":"v8.17.0","labelRegex":"^v8.17.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.16","label":"v8.16.1","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
2024-11-18 11:12:06 +01:00
Kibana Machine
4cf7f33e7c
[8.16] [Synthetics] Added error track trace to status/tls rule context variable !! (#198599) (#198671)
# Backport

This will backport the following commits from `main` to `8.16`:
- [[Synthetics] Added error track trace to status/tls rule context
variable !! (#198599)](https://github.com/elastic/kibana/pull/198599)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT
[{"author":{"name":"Shahzad","email":"shahzad31comp@gmail.com"},"sourceCommit":{"committedDate":"2024-11-01T12:55:20Z","message":"[Synthetics]
Added error track trace to status/tls rule context variable !!
(#198599)\n\n## Summary\n\nFixes
https://github.com/elastic/kibana/issues/198593\n\nAdded error track
trace to status/tls rule context variable !!\n\n<img width=\"1725\"
alt=\"image\"\nsrc=\"https://github.com/user-attachments/assets/d04fb6f3-7505-4a01-8a6f-b1b27d50ecdd\">","sha":"5544b1a31439cd8e53d431a9b118d1445eeb79a4","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","v9.0.0","ci:project-deploy-observability","Team:obs-ux-management","v8.16.0","backport:version","v8.17.0"],"title":"[Synthetics]
Added error track trace to status/tls rule context variable
!!","number":198599,"url":"https://github.com/elastic/kibana/pull/198599","mergeCommit":{"message":"[Synthetics]
Added error track trace to status/tls rule context variable !!
(#198599)\n\n## Summary\n\nFixes
https://github.com/elastic/kibana/issues/198593\n\nAdded error track
trace to status/tls rule context variable !!\n\n<img width=\"1725\"
alt=\"image\"\nsrc=\"https://github.com/user-attachments/assets/d04fb6f3-7505-4a01-8a6f-b1b27d50ecdd\">","sha":"5544b1a31439cd8e53d431a9b118d1445eeb79a4"}},"sourceBranch":"main","suggestedTargetBranches":["8.16","8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/198599","number":198599,"mergeCommit":{"message":"[Synthetics]
Added error track trace to status/tls rule context variable !!
(#198599)\n\n## Summary\n\nFixes
https://github.com/elastic/kibana/issues/198593\n\nAdded error track
trace to status/tls rule context variable !!\n\n<img width=\"1725\"
alt=\"image\"\nsrc=\"https://github.com/user-attachments/assets/d04fb6f3-7505-4a01-8a6f-b1b27d50ecdd\">","sha":"5544b1a31439cd8e53d431a9b118d1445eeb79a4"}},{"branch":"8.16","label":"v8.16.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.x","label":"v8.17.0","branchLabelMappingKey":"^v8.17.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Shahzad <shahzad31comp@gmail.com>
2024-11-01 09:41:05 -05:00
Christos Nasikas
62f11d0d8f
[8.16] [ResponseOps]]MaintenaceWindow] Increase MW table limit to 1k (#198504) (#198662)
# Backport

This will backport the following commits from `main` to `8.16`:
- [ResponseOps]]MaintenaceWindow] Increase MW table limit to 1k
(#198504) (3413cbbb)

<!--- Backport version: 8.9.8 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT
[{"author":{"name":"Julia","email":"iuliia.guskova@elastic.co"},"sourceCommit":{"committedDate":"2024-10-31T14:40:36Z","message":"[ResponseOps]]MaintenaceWindow]
Increase MW table limit to 1k (#198504)\n\nHere in this PR I am
increasing the limit for MW to 1K.\r\nEven I've changed schema for query
params(deleted maybe) I did not add\r\nadditional tests, because we
already have one integration test for the\r\ncase, when we do not have
`page` and `per_page`
params.","sha":"3413cbbb1bbe323f40cb9c6b9ff7a98a32b534d8"},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[]}]
BACKPORT-->

Co-authored-by: Julia <iuliia.guskova@elastic.co>
2024-11-01 08:47:38 -05:00
Kibana Machine
75b233224a
[8.16] [ResponseOps][MaintenanceWindow] Introduce pagination for MW find API (#197172) (#198324)
# Backport

This will backport the following commits from `main` to `8.16`:
- [[ResponseOps][MaintenanceWindow] Introduce pagination for MW find API
(#197172)](https://github.com/elastic/kibana/pull/197172)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT
[{"author":{"name":"Julia","email":"iuliia.guskova@elastic.co"},"sourceCommit":{"committedDate":"2024-10-30T12:54:58Z","message":"[ResponseOps][MaintenanceWindow]
Introduce pagination for MW find API (#197172)\n\nFixes:
https://github.com/elastic/kibana/issues/193076\r\n\r\nThis PR introduce
pagination for our MW find API.\r\n\r\nHow to test:\r\n\r\nUse
postman/insomnia/curl.\r\nDo not forget to add this header:
`x-elastic-internal-origin: Kibana`,\r\nbecause this endpoint in
internal.\r\n\r\nBasically you need to do something like
this:\r\n```\r\nGET
http://localhost:5601/top/internal/alerting/rules/maintenance_window/_find?page=3&per_page=3\r\n```\r\n\r\nTry
different page and per_page combination. Try without them.\r\n\r\n###
Checklist\r\n\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n- [x] [Flaky
Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1)
was\r\nused on any tests changed\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"6645e747070e1b7bf687227776acda2ae136fc75","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","Feature:Alerting/RulesManagement","backport:prev-major","v8.16.0","v8.17.0"],"title":"[ResponseOps][MaintenanceWindow]
Introduce pagination for MW find
API","number":197172,"url":"https://github.com/elastic/kibana/pull/197172","mergeCommit":{"message":"[ResponseOps][MaintenanceWindow]
Introduce pagination for MW find API (#197172)\n\nFixes:
https://github.com/elastic/kibana/issues/193076\r\n\r\nThis PR introduce
pagination for our MW find API.\r\n\r\nHow to test:\r\n\r\nUse
postman/insomnia/curl.\r\nDo not forget to add this header:
`x-elastic-internal-origin: Kibana`,\r\nbecause this endpoint in
internal.\r\n\r\nBasically you need to do something like
this:\r\n```\r\nGET
http://localhost:5601/top/internal/alerting/rules/maintenance_window/_find?page=3&per_page=3\r\n```\r\n\r\nTry
different page and per_page combination. Try without them.\r\n\r\n###
Checklist\r\n\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n- [x] [Flaky
Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1)
was\r\nused on any tests changed\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"6645e747070e1b7bf687227776acda2ae136fc75"}},"sourceBranch":"main","suggestedTargetBranches":["8.16","8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/197172","number":197172,"mergeCommit":{"message":"[ResponseOps][MaintenanceWindow]
Introduce pagination for MW find API (#197172)\n\nFixes:
https://github.com/elastic/kibana/issues/193076\r\n\r\nThis PR introduce
pagination for our MW find API.\r\n\r\nHow to test:\r\n\r\nUse
postman/insomnia/curl.\r\nDo not forget to add this header:
`x-elastic-internal-origin: Kibana`,\r\nbecause this endpoint in
internal.\r\n\r\nBasically you need to do something like
this:\r\n```\r\nGET
http://localhost:5601/top/internal/alerting/rules/maintenance_window/_find?page=3&per_page=3\r\n```\r\n\r\nTry
different page and per_page combination. Try without them.\r\n\r\n###
Checklist\r\n\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n- [x] [Flaky
Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1)
was\r\nused on any tests changed\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"6645e747070e1b7bf687227776acda2ae136fc75"}},{"branch":"8.16","label":"v8.16.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.x","label":"v8.17.0","branchLabelMappingKey":"^v8.17.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

---------

Co-authored-by: Julia <iuliia.guskova@elastic.co>
2024-11-01 07:02:06 -05:00
Kibana Machine
bfc8ec8ea7
[8.16] [Response Ops][Maintenance Window] Fix Maintenance Window Wildcard Scoped Queries (#194777) (#197927)
# Backport

This will backport the following commits from `main` to `8.16`:
- [[Response Ops][Maintenance Window] Fix Maintenance Window Wildcard
Scoped Queries (#194777)](https://github.com/elastic/kibana/pull/194777)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Jiawei
Wu","email":"74562234+JiaweiWu@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-26T09:47:29Z","message":"[Response
Ops][Maintenance Window] Fix Maintenance Window Wildcard Scoped Queries
(#194777)\n\n## Summary\r\n\r\nIssue:
https://github.com/elastic/sdh-kibana/issues/4923\r\n\r\nFixes
maintenance window scoped query using wildcards by injecting
the\r\n`analyze_wildcard` property to the DSL used to determine which
alerts\r\nshould be associated with the maintenance window.\r\n\r\nAlso
fixes the update route to correctly take into account the
user's\r\n`allowLeadingWildcard` flag. It was implemented for the create
route but\r\nnot the update route.\r\n\r\nFixes:
https://github.com/elastic/kibana/issues/194763\r\n\r\n### To
test:\r\n1. Install sample
data:\r\n\r\n![image](https://github.com/user-attachments/assets/4be72fc8-e4ab-47a3-b5db-48f97b1827ae)\r\n\r\n2.
Create a maintenance window with the following scoped query:
\r\n\r\n![image](https://github.com/user-attachments/assets/e2d37fd0-b957-4e76-bea3-8d954651c557)\r\n\r\n3.
Create a ES query rule and trigger
actions:\r\n\r\n![image](https://github.com/user-attachments/assets/551f5145-9ab7-48c4-a48e-e674b4f0509a)\r\n\r\n4.
Assert the `maintenance_window_id` on the 4 alerts are
set\r\n\r\n![image](https://github.com/user-attachments/assets/7ace95d3-d992-4305-a564-cf3004c9ae9e)\r\n\r\n\r\n###
Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios)\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"7ad937db574603e53aeebe69d591554801cf857b","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-major","v8.16.0","v8.17.0"],"title":"[Response
Ops][Maintenance Window] Fix Maintenance Window Wildcard Scoped
Queries","number":194777,"url":"https://github.com/elastic/kibana/pull/194777","mergeCommit":{"message":"[Response
Ops][Maintenance Window] Fix Maintenance Window Wildcard Scoped Queries
(#194777)\n\n## Summary\r\n\r\nIssue:
https://github.com/elastic/sdh-kibana/issues/4923\r\n\r\nFixes
maintenance window scoped query using wildcards by injecting
the\r\n`analyze_wildcard` property to the DSL used to determine which
alerts\r\nshould be associated with the maintenance window.\r\n\r\nAlso
fixes the update route to correctly take into account the
user's\r\n`allowLeadingWildcard` flag. It was implemented for the create
route but\r\nnot the update route.\r\n\r\nFixes:
https://github.com/elastic/kibana/issues/194763\r\n\r\n### To
test:\r\n1. Install sample
data:\r\n\r\n![image](https://github.com/user-attachments/assets/4be72fc8-e4ab-47a3-b5db-48f97b1827ae)\r\n\r\n2.
Create a maintenance window with the following scoped query:
\r\n\r\n![image](https://github.com/user-attachments/assets/e2d37fd0-b957-4e76-bea3-8d954651c557)\r\n\r\n3.
Create a ES query rule and trigger
actions:\r\n\r\n![image](https://github.com/user-attachments/assets/551f5145-9ab7-48c4-a48e-e674b4f0509a)\r\n\r\n4.
Assert the `maintenance_window_id` on the 4 alerts are
set\r\n\r\n![image](https://github.com/user-attachments/assets/7ace95d3-d992-4305-a564-cf3004c9ae9e)\r\n\r\n\r\n###
Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios)\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"7ad937db574603e53aeebe69d591554801cf857b"}},"sourceBranch":"main","suggestedTargetBranches":["8.16","8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/194777","number":194777,"mergeCommit":{"message":"[Response
Ops][Maintenance Window] Fix Maintenance Window Wildcard Scoped Queries
(#194777)\n\n## Summary\r\n\r\nIssue:
https://github.com/elastic/sdh-kibana/issues/4923\r\n\r\nFixes
maintenance window scoped query using wildcards by injecting
the\r\n`analyze_wildcard` property to the DSL used to determine which
alerts\r\nshould be associated with the maintenance window.\r\n\r\nAlso
fixes the update route to correctly take into account the
user's\r\n`allowLeadingWildcard` flag. It was implemented for the create
route but\r\nnot the update route.\r\n\r\nFixes:
https://github.com/elastic/kibana/issues/194763\r\n\r\n### To
test:\r\n1. Install sample
data:\r\n\r\n![image](https://github.com/user-attachments/assets/4be72fc8-e4ab-47a3-b5db-48f97b1827ae)\r\n\r\n2.
Create a maintenance window with the following scoped query:
\r\n\r\n![image](https://github.com/user-attachments/assets/e2d37fd0-b957-4e76-bea3-8d954651c557)\r\n\r\n3.
Create a ES query rule and trigger
actions:\r\n\r\n![image](https://github.com/user-attachments/assets/551f5145-9ab7-48c4-a48e-e674b4f0509a)\r\n\r\n4.
Assert the `maintenance_window_id` on the 4 alerts are
set\r\n\r\n![image](https://github.com/user-attachments/assets/7ace95d3-d992-4305-a564-cf3004c9ae9e)\r\n\r\n\r\n###
Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios)\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"7ad937db574603e53aeebe69d591554801cf857b"}},{"branch":"8.16","label":"v8.16.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.x","label":"v8.17.0","branchLabelMappingKey":"^v8.17.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Jiawei Wu <74562234+JiaweiWu@users.noreply.github.com>
2024-10-26 06:28:39 -05:00
Kibana Machine
d77d619e17
[8.16] [ResponseOps][Rules] Remove unintended internal Find routes API with public access (#193757) (#197358)
# Backport

This will backport the following commits from `main` to `8.16`:
- [[ResponseOps][Rules] Remove unintended internal Find routes API with
public access (#193757)](https://github.com/elastic/kibana/pull/193757)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Zacqary Adam
Xeper","email":"Zacqary@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-23T04:33:31Z","message":"[ResponseOps][Rules]
Remove unintended internal Find routes API with public access
(#193757)\n\n## Summary\r\n\r\nFixes #192957 \r\n\r\nRemoves the
`internal/_find` route from public access by moving the\r\nhard-coded
`options` into the route builder
functions.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"196cabad9bbd0511219fc7833a62cb8a0bb61514","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","Team:ResponseOps","v9.0.0","Feature:Alerting/RulesFramework","backport:prev-minor","ci:project-deploy-observability","v8.16.0"],"title":"[ResponseOps][Rules]
Remove unintended internal Find routes API with public
access","number":193757,"url":"https://github.com/elastic/kibana/pull/193757","mergeCommit":{"message":"[ResponseOps][Rules]
Remove unintended internal Find routes API with public access
(#193757)\n\n## Summary\r\n\r\nFixes #192957 \r\n\r\nRemoves the
`internal/_find` route from public access by moving the\r\nhard-coded
`options` into the route builder
functions.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"196cabad9bbd0511219fc7833a62cb8a0bb61514"}},"sourceBranch":"main","suggestedTargetBranches":["8.16"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/193757","number":193757,"mergeCommit":{"message":"[ResponseOps][Rules]
Remove unintended internal Find routes API with public access
(#193757)\n\n## Summary\r\n\r\nFixes #192957 \r\n\r\nRemoves the
`internal/_find` route from public access by moving the\r\nhard-coded
`options` into the route builder
functions.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"196cabad9bbd0511219fc7833a62cb8a0bb61514"}},{"branch":"8.16","label":"v8.16.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Zacqary Adam Xeper <Zacqary@users.noreply.github.com>
2024-10-23 01:13:58 -05:00
Kibana Machine
b9820cc067
[8.x] Skip scheduling actions for the alerts without scheduledActions (#195948) (#196458)
# Backport

This will backport the following commits from `main` to `8.x`:
- [Skip scheduling actions for the alerts without scheduledActions
(#195948)](https://github.com/elastic/kibana/pull/195948)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Ersin
Erdal","email":"92688503+ersin-erdal@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-15T23:40:19Z","message":"Skip
scheduling actions for the alerts without scheduledActions
(#195948)\n\nResolves: #190258\r\n\r\nAs a result of #190258, we have
found out that the odd behaviour happens\r\nwhen an existing alert is
pushed above the max alerts limit by a
new\r\nalert.\r\n\r\nScenario:\r\n\r\n1. The rule type detects 4 alerts
(`alert-1`, `alert-2`, `alert-3`,\r\n`alert-4`),\r\nBut reports only the
first 3 as the max alerts limit is 3.\r\n\r\n2. `alert-2` becomes
recovered, therefore the rule type reports 3 active\r\n(`alert-1`,
`alert-3`, `alert-4`), 1 recovered (`alert-2`) alert.\r\n\r\n3. Alerts
`alert-1`, `alert-3`, `alert-4` are saved in the task state.\r\n\r\n4.
`alert-2` becomes active again (the others are still active)\r\n\r\n5.
Rule type reports 3 active alerts (`alert-1`, `alert-2`,
`alert-3`)\r\n\r\n6. As a result, the action scheduler tries to schedule
actions for\r\n`alert-1`, `alert-3`, `alert-4` as they are the existing
alerts.\r\nBut, since the rule type didn't report the `alert-4` it has
no scheduled\r\nactions, therefore the action scheduler assumes it is
recovered and\r\ntries to schedule a recovery action.\r\n\r\nThis PR
changes the actionScheduler to handle active and recovered\r\nalerts
separately.\r\nWith this change, no action would be scheduled for an
alert from\r\nprevious run (exists in the task state) and isn't reported
by the\r\nruleTypeExecutor due to max-alerts-limit but it would be kept
in the\r\ntask
state.","sha":"dd25bf8807c3ff3982d455f070b6e6c65233662d","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","Team:ResponseOps","v9.0.0","backport:prev-minor"],"title":"Skip
scheduling actions for the alerts without
scheduledActions","number":195948,"url":"https://github.com/elastic/kibana/pull/195948","mergeCommit":{"message":"Skip
scheduling actions for the alerts without scheduledActions
(#195948)\n\nResolves: #190258\r\n\r\nAs a result of #190258, we have
found out that the odd behaviour happens\r\nwhen an existing alert is
pushed above the max alerts limit by a
new\r\nalert.\r\n\r\nScenario:\r\n\r\n1. The rule type detects 4 alerts
(`alert-1`, `alert-2`, `alert-3`,\r\n`alert-4`),\r\nBut reports only the
first 3 as the max alerts limit is 3.\r\n\r\n2. `alert-2` becomes
recovered, therefore the rule type reports 3 active\r\n(`alert-1`,
`alert-3`, `alert-4`), 1 recovered (`alert-2`) alert.\r\n\r\n3. Alerts
`alert-1`, `alert-3`, `alert-4` are saved in the task state.\r\n\r\n4.
`alert-2` becomes active again (the others are still active)\r\n\r\n5.
Rule type reports 3 active alerts (`alert-1`, `alert-2`,
`alert-3`)\r\n\r\n6. As a result, the action scheduler tries to schedule
actions for\r\n`alert-1`, `alert-3`, `alert-4` as they are the existing
alerts.\r\nBut, since the rule type didn't report the `alert-4` it has
no scheduled\r\nactions, therefore the action scheduler assumes it is
recovered and\r\ntries to schedule a recovery action.\r\n\r\nThis PR
changes the actionScheduler to handle active and recovered\r\nalerts
separately.\r\nWith this change, no action would be scheduled for an
alert from\r\nprevious run (exists in the task state) and isn't reported
by the\r\nruleTypeExecutor due to max-alerts-limit but it would be kept
in the\r\ntask
state.","sha":"dd25bf8807c3ff3982d455f070b6e6c65233662d"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/195948","number":195948,"mergeCommit":{"message":"Skip
scheduling actions for the alerts without scheduledActions
(#195948)\n\nResolves: #190258\r\n\r\nAs a result of #190258, we have
found out that the odd behaviour happens\r\nwhen an existing alert is
pushed above the max alerts limit by a
new\r\nalert.\r\n\r\nScenario:\r\n\r\n1. The rule type detects 4 alerts
(`alert-1`, `alert-2`, `alert-3`,\r\n`alert-4`),\r\nBut reports only the
first 3 as the max alerts limit is 3.\r\n\r\n2. `alert-2` becomes
recovered, therefore the rule type reports 3 active\r\n(`alert-1`,
`alert-3`, `alert-4`), 1 recovered (`alert-2`) alert.\r\n\r\n3. Alerts
`alert-1`, `alert-3`, `alert-4` are saved in the task state.\r\n\r\n4.
`alert-2` becomes active again (the others are still active)\r\n\r\n5.
Rule type reports 3 active alerts (`alert-1`, `alert-2`,
`alert-3`)\r\n\r\n6. As a result, the action scheduler tries to schedule
actions for\r\n`alert-1`, `alert-3`, `alert-4` as they are the existing
alerts.\r\nBut, since the rule type didn't report the `alert-4` it has
no scheduled\r\nactions, therefore the action scheduler assumes it is
recovered and\r\ntries to schedule a recovery action.\r\n\r\nThis PR
changes the actionScheduler to handle active and recovered\r\nalerts
separately.\r\nWith this change, no action would be scheduled for an
alert from\r\nprevious run (exists in the task state) and isn't reported
by the\r\nruleTypeExecutor due to max-alerts-limit but it would be kept
in the\r\ntask
state.","sha":"dd25bf8807c3ff3982d455f070b6e6c65233662d"}}]}]
BACKPORT-->

Co-authored-by: Ersin Erdal <92688503+ersin-erdal@users.noreply.github.com>
2024-10-15 20:18:36 -05:00
Ying Mao
d5d39e5974
[8.x] Adding model versions for all remaining so types without model versions (#195500) (#196457)
# Backport

This will backport the following commits from `main` to `8.x`:
- [Adding model versions for all remaining so types without model
versions (#195500)](https://github.com/elastic/kibana/pull/195500)

<!--- Backport version: 8.9.8 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Ying
Mao","email":"ying.mao@elastic.co"},"sourceCommit":{"committedDate":"2024-10-15T22:22:46Z","message":"Adding
model versions for all remaining so types without model versions
(#195500)\n\nResolves
https://github.com/elastic/kibana/issues/184618\r\n\r\n##
Summary\r\n\r\nAdds v1 schemas for all remaining Response Ops owned
saved object types:\r\n* `connector_token`\r\n*
`api_key_pending_invalidation`\r\n* `maintenance-window`\r\n*
`rules-settings`\r\n\r\n## To Verify\r\n\r\n1. Run ES and Kibana on
`main` and create saved objects for each of the\r\nabove types:\r\na.
Create an OAuth ServiceNow ITOM connector to create
a\r\n`connector_token` saved object\r\nb. Create a rule, let it run, and
then delete the rule. This will create\r\nan
`api_key_pending_invalidation` SO and 2 `rules-settings` SOs\r\n c.
Create some maintenance windows, both with and without filters\r\n2.
Keep ES running and switch to this branch and restart Kibana.
Then\r\nverify you can read and modify the existing SOs with no
errors\r\na. Test the ServiceNow ITOM connector, which should read
the\r\n`connector_token` SO\r\nb. Modify the rules settings and then run
a rule to ensure they're\r\nloaded with no errors\r\n c. Load the
maintenance window UI and edit a MW\r\n\r\nCo-authored-by: Elastic
Machine
<elasticmachine@users.noreply.github.com>","sha":"d9cd17bdbd47d66968bd5fda6fb32a08134fbc2d","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Feature:Actions","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"number":195500,"url":"https://github.com/elastic/kibana/pull/195500","mergeCommit":{"message":"Adding
model versions for all remaining so types without model versions
(#195500)\n\nResolves
https://github.com/elastic/kibana/issues/184618\r\n\r\n##
Summary\r\n\r\nAdds v1 schemas for all remaining Response Ops owned
saved object types:\r\n* `connector_token`\r\n*
`api_key_pending_invalidation`\r\n* `maintenance-window`\r\n*
`rules-settings`\r\n\r\n## To Verify\r\n\r\n1. Run ES and Kibana on
`main` and create saved objects for each of the\r\nabove types:\r\na.
Create an OAuth ServiceNow ITOM connector to create
a\r\n`connector_token` saved object\r\nb. Create a rule, let it run, and
then delete the rule. This will create\r\nan
`api_key_pending_invalidation` SO and 2 `rules-settings` SOs\r\n c.
Create some maintenance windows, both with and without filters\r\n2.
Keep ES running and switch to this branch and restart Kibana.
Then\r\nverify you can read and modify the existing SOs with no
errors\r\na. Test the ServiceNow ITOM connector, which should read
the\r\n`connector_token` SO\r\nb. Modify the rules settings and then run
a rule to ensure they're\r\nloaded with no errors\r\n c. Load the
maintenance window UI and edit a MW\r\n\r\nCo-authored-by: Elastic
Machine
<elasticmachine@users.noreply.github.com>","sha":"d9cd17bdbd47d66968bd5fda6fb32a08134fbc2d"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/195500","number":195500,"mergeCommit":{"message":"Adding
model versions for all remaining so types without model versions
(#195500)\n\nResolves
https://github.com/elastic/kibana/issues/184618\r\n\r\n##
Summary\r\n\r\nAdds v1 schemas for all remaining Response Ops owned
saved object types:\r\n* `connector_token`\r\n*
`api_key_pending_invalidation`\r\n* `maintenance-window`\r\n*
`rules-settings`\r\n\r\n## To Verify\r\n\r\n1. Run ES and Kibana on
`main` and create saved objects for each of the\r\nabove types:\r\na.
Create an OAuth ServiceNow ITOM connector to create
a\r\n`connector_token` saved object\r\nb. Create a rule, let it run, and
then delete the rule. This will create\r\nan
`api_key_pending_invalidation` SO and 2 `rules-settings` SOs\r\n c.
Create some maintenance windows, both with and without filters\r\n2.
Keep ES running and switch to this branch and restart Kibana.
Then\r\nverify you can read and modify the existing SOs with no
errors\r\na. Test the ServiceNow ITOM connector, which should read
the\r\n`connector_token` SO\r\nb. Modify the rules settings and then run
a rule to ensure they're\r\nloaded with no errors\r\n c. Load the
maintenance window UI and edit a MW\r\n\r\nCo-authored-by: Elastic
Machine
<elasticmachine@users.noreply.github.com>","sha":"d9cd17bdbd47d66968bd5fda6fb32a08134fbc2d"}},{"branch":"8.x","label":"v8.16.0","labelRegex":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
2024-10-15 20:15:16 -05:00
Julian Gernun
b2ba109781
[8.x] [Response Ops][Rules] OAS Ready Rule API (#196150) (#196318)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Rules] OAS Ready Rule API
(#196150)](https://github.com/elastic/kibana/pull/196150)

<!--- Backport version: 8.9.8 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Julian
Gernun","email":"17549662+jcger@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-15T12:50:35Z","message":"[Response
Ops][Rules] OAS Ready Rule API (#196150)\n\n## Summary\r\n\r\nLinked to
https://github.com/elastic/kibana/issues/195182\r\n\r\n### muteAll
\r\n\r\n- added 40x error codes to response\r\n- `public` access prop
already
set\r\n[here](8545b9ccfb/x-pack/plugins/alerting/server/routes/rule/apis/mute_all/mute_all_rule.ts (L28))\r\n-
request schema already with
description\r\n[here](8545b9ccfb/x-pack/plugins/alerting/common/routes/rule/apis/mute_all/schemas/v1.ts (L11))\r\n-
no response schema\r\n\r\n### unmuteAll\r\n\r\n- added 40x error codes
to response\r\n- `public` access prop already
set\r\n[here](563910b672/x-pack/plugins/alerting/server/routes/rule/apis/unmute_all/unmute_all_rule.ts (L25))\r\n-
params schema already with
description\r\n[here](563910b672/x-pack/plugins/alerting/common/routes/rule/apis/unmute_all/schemas/v1.ts (L11))\r\n-
no response schema\r\n\r\n### rule types\r\n\r\n- added 40x error code
to response\r\n- `public` access prop already
set\r\n[here](563910b672/x-pack/plugins/alerting/server/routes/rule/apis/list_types/rule_types.ts (L23))\r\n-
no request schema\r\n- added response schema
descriptions\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"611082ab3178efcc0cd6a9e073c409e4969aa618","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"number":196150,"url":"https://github.com/elastic/kibana/pull/196150","mergeCommit":{"message":"[Response
Ops][Rules] OAS Ready Rule API (#196150)\n\n## Summary\r\n\r\nLinked to
https://github.com/elastic/kibana/issues/195182\r\n\r\n### muteAll
\r\n\r\n- added 40x error codes to response\r\n- `public` access prop
already
set\r\n[here](8545b9ccfb/x-pack/plugins/alerting/server/routes/rule/apis/mute_all/mute_all_rule.ts (L28))\r\n-
request schema already with
description\r\n[here](8545b9ccfb/x-pack/plugins/alerting/common/routes/rule/apis/mute_all/schemas/v1.ts (L11))\r\n-
no response schema\r\n\r\n### unmuteAll\r\n\r\n- added 40x error codes
to response\r\n- `public` access prop already
set\r\n[here](563910b672/x-pack/plugins/alerting/server/routes/rule/apis/unmute_all/unmute_all_rule.ts (L25))\r\n-
params schema already with
description\r\n[here](563910b672/x-pack/plugins/alerting/common/routes/rule/apis/unmute_all/schemas/v1.ts (L11))\r\n-
no response schema\r\n\r\n### rule types\r\n\r\n- added 40x error code
to response\r\n- `public` access prop already
set\r\n[here](563910b672/x-pack/plugins/alerting/server/routes/rule/apis/list_types/rule_types.ts (L23))\r\n-
no request schema\r\n- added response schema
descriptions\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"611082ab3178efcc0cd6a9e073c409e4969aa618"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/196150","number":196150,"mergeCommit":{"message":"[Response
Ops][Rules] OAS Ready Rule API (#196150)\n\n## Summary\r\n\r\nLinked to
https://github.com/elastic/kibana/issues/195182\r\n\r\n### muteAll
\r\n\r\n- added 40x error codes to response\r\n- `public` access prop
already
set\r\n[here](8545b9ccfb/x-pack/plugins/alerting/server/routes/rule/apis/mute_all/mute_all_rule.ts (L28))\r\n-
request schema already with
description\r\n[here](8545b9ccfb/x-pack/plugins/alerting/common/routes/rule/apis/mute_all/schemas/v1.ts (L11))\r\n-
no response schema\r\n\r\n### unmuteAll\r\n\r\n- added 40x error codes
to response\r\n- `public` access prop already
set\r\n[here](563910b672/x-pack/plugins/alerting/server/routes/rule/apis/unmute_all/unmute_all_rule.ts (L25))\r\n-
params schema already with
description\r\n[here](563910b672/x-pack/plugins/alerting/common/routes/rule/apis/unmute_all/schemas/v1.ts (L11))\r\n-
no response schema\r\n\r\n### rule types\r\n\r\n- added 40x error code
to response\r\n- `public` access prop already
set\r\n[here](563910b672/x-pack/plugins/alerting/server/routes/rule/apis/list_types/rule_types.ts (L23))\r\n-
no request schema\r\n- added response schema
descriptions\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"611082ab3178efcc0cd6a9e073c409e4969aa618"}},{"branch":"8.x","label":"v8.16.0","labelRegex":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
2024-10-15 12:59:19 -05:00
Kibana Machine
c156cb3816
[8.x] [Response Ops][Rules] Version Get Rule Types API (#195361) (#196175)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Rules] Version Get Rule Types API
(#195361)](https://github.com/elastic/kibana/pull/195361)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Julian
Gernun","email":"17549662+jcger@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-14T15:46:17Z","message":"[Response
Ops][Rules] Version Get Rule Types API (#195361)\n\n##
Summary\r\n\r\n`GET /api/alerting/rule_types` item
in\r\nhttps://github.com/elastic/kibana/issues/195181","sha":"512a31d7a1e42139c2e1b26e961b2226ace3836d","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[Response
Ops][Rules] Version Get Rule Types
API","number":195361,"url":"https://github.com/elastic/kibana/pull/195361","mergeCommit":{"message":"[Response
Ops][Rules] Version Get Rule Types API (#195361)\n\n##
Summary\r\n\r\n`GET /api/alerting/rule_types` item
in\r\nhttps://github.com/elastic/kibana/issues/195181","sha":"512a31d7a1e42139c2e1b26e961b2226ace3836d"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/195361","number":195361,"mergeCommit":{"message":"[Response
Ops][Rules] Version Get Rule Types API (#195361)\n\n##
Summary\r\n\r\n`GET /api/alerting/rule_types` item
in\r\nhttps://github.com/elastic/kibana/issues/195181","sha":"512a31d7a1e42139c2e1b26e961b2226ace3836d"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Julian Gernun <17549662+jcger@users.noreply.github.com>
2024-10-15 11:02:48 -05:00
Kibana Machine
5a67e4d2e1
[8.x] Update dependency @types/lodash to ^4.17.10 (main) (#194739) (#196234)
# Backport

This will backport the following commits from `main` to `8.x`:
- [Update dependency @types/lodash to ^4.17.10 (main)
(#194739)](https://github.com/elastic/kibana/pull/194739)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT
[{"author":{"name":"elastic-renovate-prod[bot]","email":"174716857+elastic-renovate-prod[bot]@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-15T06:21:03Z","message":"Update
dependency @types/lodash to ^4.17.10 (main)
(#194739)","sha":"563910b672b6dbe4f9e7931e36ec41e674fe8eb3","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Core","Feature:ExpressionLanguage","release_note:skip","💝community","v9.0.0","backport:prev-minor","ci:project-deploy-observability","Team:obs-ux-infra_services","Team:obs-ux-management"],"title":"Update
dependency @types/lodash to ^4.17.10
(main)","number":194739,"url":"https://github.com/elastic/kibana/pull/194739","mergeCommit":{"message":"Update
dependency @types/lodash to ^4.17.10 (main)
(#194739)","sha":"563910b672b6dbe4f9e7931e36ec41e674fe8eb3"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/194739","number":194739,"mergeCommit":{"message":"Update
dependency @types/lodash to ^4.17.10 (main)
(#194739)","sha":"563910b672b6dbe4f9e7931e36ec41e674fe8eb3"}}]}]
BACKPORT-->

Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
2024-10-15 04:11:15 -05:00
Kibana Machine
fadc97658c
[8.x] [Response Ops][Rules] Version Unmute All Rule API (#196070) (#196170)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Rules] Version Unmute All Rule API
(#196070)](https://github.com/elastic/kibana/pull/196070)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Julian
Gernun","email":"17549662+jcger@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-14T15:28:57Z","message":"[Response
Ops][Rules] Version Unmute All Rule API (#196070)\n\n##
Summary\r\n\r\n`POST /api/alerting/rule/{id}/_unmute_all`
in\r\nhttps://github.com/elastic/kibana/issues/195181","sha":"c901fec4f1ea9407265e6f450a5a9390fa31454b","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[Response
Ops][Rules] Version Unmute All Rule
API","number":196070,"url":"https://github.com/elastic/kibana/pull/196070","mergeCommit":{"message":"[Response
Ops][Rules] Version Unmute All Rule API (#196070)\n\n##
Summary\r\n\r\n`POST /api/alerting/rule/{id}/_unmute_all`
in\r\nhttps://github.com/elastic/kibana/issues/195181","sha":"c901fec4f1ea9407265e6f450a5a9390fa31454b"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/196070","number":196070,"mergeCommit":{"message":"[Response
Ops][Rules] Version Unmute All Rule API (#196070)\n\n##
Summary\r\n\r\n`POST /api/alerting/rule/{id}/_unmute_all`
in\r\nhttps://github.com/elastic/kibana/issues/195181","sha":"c901fec4f1ea9407265e6f450a5a9390fa31454b"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Julian Gernun <17549662+jcger@users.noreply.github.com>
2024-10-14 12:24:16 -05:00
Kibana Machine
eca46fe4bc
[8.x] Execution type field (#195884) (#196152)
# Backport

This will backport the following commits from `main` to `8.x`:
- [Execution type field
(#195884)](https://github.com/elastic/kibana/pull/195884)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Khristinin
Nikita","email":"nikita.khristinin@elastic.co"},"sourceCommit":{"committedDate":"2024-10-14T14:29:12Z","message":"Execution
type field (#195884)\n\n## Added new field - execution type for
alerts\r\n\r\nAdded new field only for security type
alerts:\r\n\r\n`kibana.alert.rule.execution.type` - can be `manual` or
`scheduled`\r\n\r\nAlso, move intended timestamp settings
from\r\n`create_persistence_rule_type_wrapper` to
`build_alert`\r\n\r\nAlso added those new field to Alert schema and
types.\r\n\r\n\r\n\r\nhttps://github.com/user-attachments/assets/c5b021a6-4763-47ae-b46c-814a138be65a\r\n\r\n\r\n\r\nFor
tests:\r\n\r\n- tests all rule types with and without
suppression:\r\n`kibana.alert.rule.execution.type` - should be
`scheduled`,\r\n`kibana.alert.intended_timestamp` - should equal alert
timestamp\r\n\r\n- tests all rules with and without suppression with
manual run -\r\n`kibana.alert.rule.execution.type` - should be
`manual`,\r\n`kibana.alert.intended_timestamp` - should equal date
inside you manual\r\nrule run date
range\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"3d466a72a8ab181aadf562ab6c27a5affa32dc96","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","backport:prev-minor"],"title":"Execution
type
field","number":195884,"url":"https://github.com/elastic/kibana/pull/195884","mergeCommit":{"message":"Execution
type field (#195884)\n\n## Added new field - execution type for
alerts\r\n\r\nAdded new field only for security type
alerts:\r\n\r\n`kibana.alert.rule.execution.type` - can be `manual` or
`scheduled`\r\n\r\nAlso, move intended timestamp settings
from\r\n`create_persistence_rule_type_wrapper` to
`build_alert`\r\n\r\nAlso added those new field to Alert schema and
types.\r\n\r\n\r\n\r\nhttps://github.com/user-attachments/assets/c5b021a6-4763-47ae-b46c-814a138be65a\r\n\r\n\r\n\r\nFor
tests:\r\n\r\n- tests all rule types with and without
suppression:\r\n`kibana.alert.rule.execution.type` - should be
`scheduled`,\r\n`kibana.alert.intended_timestamp` - should equal alert
timestamp\r\n\r\n- tests all rules with and without suppression with
manual run -\r\n`kibana.alert.rule.execution.type` - should be
`manual`,\r\n`kibana.alert.intended_timestamp` - should equal date
inside you manual\r\nrule run date
range\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"3d466a72a8ab181aadf562ab6c27a5affa32dc96"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/195884","number":195884,"mergeCommit":{"message":"Execution
type field (#195884)\n\n## Added new field - execution type for
alerts\r\n\r\nAdded new field only for security type
alerts:\r\n\r\n`kibana.alert.rule.execution.type` - can be `manual` or
`scheduled`\r\n\r\nAlso, move intended timestamp settings
from\r\n`create_persistence_rule_type_wrapper` to
`build_alert`\r\n\r\nAlso added those new field to Alert schema and
types.\r\n\r\n\r\n\r\nhttps://github.com/user-attachments/assets/c5b021a6-4763-47ae-b46c-814a138be65a\r\n\r\n\r\n\r\nFor
tests:\r\n\r\n- tests all rule types with and without
suppression:\r\n`kibana.alert.rule.execution.type` - should be
`scheduled`,\r\n`kibana.alert.intended_timestamp` - should equal alert
timestamp\r\n\r\n- tests all rules with and without suppression with
manual run -\r\n`kibana.alert.rule.execution.type` - should be
`manual`,\r\n`kibana.alert.intended_timestamp` - should equal date
inside you manual\r\nrule run date
range\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"3d466a72a8ab181aadf562ab6c27a5affa32dc96"}}]}]
BACKPORT-->

Co-authored-by: Khristinin Nikita <nikita.khristinin@elastic.co>
2024-10-14 11:20:53 -05:00
Kibana Machine
7aa0e2a0fd
[8.x] [Response Ops][Rules] Version Mute All Rule API (#195572) (#196125)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Rules] Version Mute All Rule API
(#195572)](https://github.com/elastic/kibana/pull/195572)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Julian
Gernun","email":"17549662+jcger@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-14T12:18:42Z","message":"[Response
Ops][Rules] Version Mute All Rule API (#195572)\n\n##
Summary\r\n\r\n`POST /api/alerting/rule/{id}/_mute_all`
in\r\nhttps://github.com/elastic/kibana/issues/195181","sha":"f787b852b23139fbc8e9926263d827ded4a1f451","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[Response
Ops][Rules] Version Mute All Rule
API","number":195572,"url":"https://github.com/elastic/kibana/pull/195572","mergeCommit":{"message":"[Response
Ops][Rules] Version Mute All Rule API (#195572)\n\n##
Summary\r\n\r\n`POST /api/alerting/rule/{id}/_mute_all`
in\r\nhttps://github.com/elastic/kibana/issues/195181","sha":"f787b852b23139fbc8e9926263d827ded4a1f451"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/195572","number":195572,"mergeCommit":{"message":"[Response
Ops][Rules] Version Mute All Rule API (#195572)\n\n##
Summary\r\n\r\n`POST /api/alerting/rule/{id}/_mute_all`
in\r\nhttps://github.com/elastic/kibana/issues/195181","sha":"f787b852b23139fbc8e9926263d827ded4a1f451"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Julian Gernun <17549662+jcger@users.noreply.github.com>
2024-10-14 09:28:57 -05:00
Kibana Machine
34b8d2b748
[8.x] [ResponseOps][Alerts] Fix DSL filter issues in search bar (#193623) (#196033)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[ResponseOps][Alerts] Fix DSL filter issues in search bar
(#193623)](https://github.com/elastic/kibana/pull/193623)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Janki
Salvi","email":"117571355+js-jankisalvi@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-13T18:42:04Z","message":"[ResponseOps][Alerts]
Fix DSL filter issues in search bar (#193623)\n\n##
Summary\r\n\r\nResolves
https://github.com/elastic/kibana/issues/183908\r\nResolves
https://github.com/elastic/kibana/issues/192557\r\n\r\nThis PR fixes an
issue of DSL filter in\r\n<details><summary>Search bar in Alerts page of
Stack\r\nmanagement</summary>\r\n<img width=\"1237\"
alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/b9b380d2-80a7-4754-95f2-6b6831923c4d\">\r\n</details>
\r\n\r\n<details><summary>Search bar in Alerts page of
Observability</summary>\r\n<img width=\"1237\"
alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/68ceb97f-b958-47f4-b356-757cbafd9170\">\r\n</details>
\r\n\r\n<details><summary>Search bar in \"If alerts matches query\"
action\r\nfilter</summary>\r\n<img width=\"1281\"
alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/1f99ca43-c4b5-4f52-b50f-914f1e205c5b\">\r\n</details>
\r\n\r\n<details><summary>Search bar in Maintenance window
page</summary>\r\n<img width=\"1272\"
alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/ffaa317d-c14b-45a2-9d02-00f7a10239ab\">\r\n</details>
\r\n\r\n\r\n### Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n### How to
verify\r\n- Create a DSL filter in above mentioned pages\r\n- Verify
that filter is applied properly\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"122647b7c286f5c6a429e73166ff2dd542779f04","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[ResponseOps][Alerts]
Fix DSL filter issues in search
bar","number":193623,"url":"https://github.com/elastic/kibana/pull/193623","mergeCommit":{"message":"[ResponseOps][Alerts]
Fix DSL filter issues in search bar (#193623)\n\n##
Summary\r\n\r\nResolves
https://github.com/elastic/kibana/issues/183908\r\nResolves
https://github.com/elastic/kibana/issues/192557\r\n\r\nThis PR fixes an
issue of DSL filter in\r\n<details><summary>Search bar in Alerts page of
Stack\r\nmanagement</summary>\r\n<img width=\"1237\"
alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/b9b380d2-80a7-4754-95f2-6b6831923c4d\">\r\n</details>
\r\n\r\n<details><summary>Search bar in Alerts page of
Observability</summary>\r\n<img width=\"1237\"
alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/68ceb97f-b958-47f4-b356-757cbafd9170\">\r\n</details>
\r\n\r\n<details><summary>Search bar in \"If alerts matches query\"
action\r\nfilter</summary>\r\n<img width=\"1281\"
alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/1f99ca43-c4b5-4f52-b50f-914f1e205c5b\">\r\n</details>
\r\n\r\n<details><summary>Search bar in Maintenance window
page</summary>\r\n<img width=\"1272\"
alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/ffaa317d-c14b-45a2-9d02-00f7a10239ab\">\r\n</details>
\r\n\r\n\r\n### Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n### How to
verify\r\n- Create a DSL filter in above mentioned pages\r\n- Verify
that filter is applied properly\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"122647b7c286f5c6a429e73166ff2dd542779f04"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/193623","number":193623,"mergeCommit":{"message":"[ResponseOps][Alerts]
Fix DSL filter issues in search bar (#193623)\n\n##
Summary\r\n\r\nResolves
https://github.com/elastic/kibana/issues/183908\r\nResolves
https://github.com/elastic/kibana/issues/192557\r\n\r\nThis PR fixes an
issue of DSL filter in\r\n<details><summary>Search bar in Alerts page of
Stack\r\nmanagement</summary>\r\n<img width=\"1237\"
alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/b9b380d2-80a7-4754-95f2-6b6831923c4d\">\r\n</details>
\r\n\r\n<details><summary>Search bar in Alerts page of
Observability</summary>\r\n<img width=\"1237\"
alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/68ceb97f-b958-47f4-b356-757cbafd9170\">\r\n</details>
\r\n\r\n<details><summary>Search bar in \"If alerts matches query\"
action\r\nfilter</summary>\r\n<img width=\"1281\"
alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/1f99ca43-c4b5-4f52-b50f-914f1e205c5b\">\r\n</details>
\r\n\r\n<details><summary>Search bar in Maintenance window
page</summary>\r\n<img width=\"1272\"
alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/ffaa317d-c14b-45a2-9d02-00f7a10239ab\">\r\n</details>
\r\n\r\n\r\n### Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n### How to
verify\r\n- Create a DSL filter in above mentioned pages\r\n- Verify
that filter is applied properly\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"122647b7c286f5c6a429e73166ff2dd542779f04"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Janki Salvi <117571355+js-jankisalvi@users.noreply.github.com>
2024-10-13 15:32:32 -05:00
Kibana Machine
a1c4495d2a
[8.x] [Synthetics] Add service name/labels to alerts and contexts (#195621) (#196002)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Synthetics] Add service name/labels to alerts and contexts
(#195621)](https://github.com/elastic/kibana/pull/195621)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT
[{"author":{"name":"Shahzad","email":"shahzad31comp@gmail.com"},"sourceCommit":{"committedDate":"2024-10-11T22:40:57Z","message":"[Synthetics]
Add service name/labels to alerts and contexts (#195621)\n\n##
Summary\r\n\r\nAdd service name to alerts
!!\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"f9417fbdc2e95492f958d84c6d87787420d0fc7f","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","backport:prev-minor","ci:project-deploy-observability","Team:obs-ux-management"],"title":"[Synthetics]
Add service name/labels to alerts and
contexts","number":195621,"url":"https://github.com/elastic/kibana/pull/195621","mergeCommit":{"message":"[Synthetics]
Add service name/labels to alerts and contexts (#195621)\n\n##
Summary\r\n\r\nAdd service name to alerts
!!\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"f9417fbdc2e95492f958d84c6d87787420d0fc7f"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/195621","number":195621,"mergeCommit":{"message":"[Synthetics]
Add service name/labels to alerts and contexts (#195621)\n\n##
Summary\r\n\r\nAdd service name to alerts
!!\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"f9417fbdc2e95492f958d84c6d87787420d0fc7f"}}]}]
BACKPORT-->

Co-authored-by: Shahzad <shahzad31comp@gmail.com>
2024-10-11 19:20:21 -05:00
Kibana Machine
6df1c38fc3
[8.x] [ResponseOps][Flapping] Add Rule Specific Flapping Form to New Rule Form Page (#194516) (#195697)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[ResponseOps][Flapping] Add Rule Specific Flapping Form to New Rule
Form Page (#194516)](https://github.com/elastic/kibana/pull/194516)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Jiawei
Wu","email":"74562234+JiaweiWu@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-10T02:01:58Z","message":"[ResponseOps][Flapping]
Add Rule Specific Flapping Form to New Rule Form Page (#194516)\n\n##
Summary\r\n\r\nDepends on:
https://github.com/elastic/kibana/pull/194086\r\nDesigns:\r\nhttps://www.figma.com/design/eTr6WsKzhSLcQ24AlgrY8R/Flapping-per-Rule--%3E-%23294?node-id=5265-29867&node-type=frame&t=1VfgdlcjkSHmpbje-0\r\n\r\nAdds
the rule specific flapping form to the new rule form page. \r\n\r\n## To
test:\r\n\r\n1. change `IS_RULE_SPECIFIC_FLAPPING_ENABLED` to true
\r\n2. run `yarn start --run-examples`\r\n3. assert the new flapping UI
exists by going to developer examples ->\r\ncreate/edit rule\r\n\r\n<img
width=\"1162\" alt=\"Screenshot 2024-09-30 at 11 43
16 PM\"\r\nsrc=\"https://github.com/user-attachments/assets/a1275a49-f2ed-43ce-815b-5c0bd93770e5\">\r\n\r\n###
Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"447617e2be18cbf8fdd495cb4b9570921b7fd467","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[ResponseOps][Flapping]
Add Rule Specific Flapping Form to New Rule Form
Page","number":194516,"url":"https://github.com/elastic/kibana/pull/194516","mergeCommit":{"message":"[ResponseOps][Flapping]
Add Rule Specific Flapping Form to New Rule Form Page (#194516)\n\n##
Summary\r\n\r\nDepends on:
https://github.com/elastic/kibana/pull/194086\r\nDesigns:\r\nhttps://www.figma.com/design/eTr6WsKzhSLcQ24AlgrY8R/Flapping-per-Rule--%3E-%23294?node-id=5265-29867&node-type=frame&t=1VfgdlcjkSHmpbje-0\r\n\r\nAdds
the rule specific flapping form to the new rule form page. \r\n\r\n## To
test:\r\n\r\n1. change `IS_RULE_SPECIFIC_FLAPPING_ENABLED` to true
\r\n2. run `yarn start --run-examples`\r\n3. assert the new flapping UI
exists by going to developer examples ->\r\ncreate/edit rule\r\n\r\n<img
width=\"1162\" alt=\"Screenshot 2024-09-30 at 11 43
16 PM\"\r\nsrc=\"https://github.com/user-attachments/assets/a1275a49-f2ed-43ce-815b-5c0bd93770e5\">\r\n\r\n###
Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"447617e2be18cbf8fdd495cb4b9570921b7fd467"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/194516","number":194516,"mergeCommit":{"message":"[ResponseOps][Flapping]
Add Rule Specific Flapping Form to New Rule Form Page (#194516)\n\n##
Summary\r\n\r\nDepends on:
https://github.com/elastic/kibana/pull/194086\r\nDesigns:\r\nhttps://www.figma.com/design/eTr6WsKzhSLcQ24AlgrY8R/Flapping-per-Rule--%3E-%23294?node-id=5265-29867&node-type=frame&t=1VfgdlcjkSHmpbje-0\r\n\r\nAdds
the rule specific flapping form to the new rule form page. \r\n\r\n## To
test:\r\n\r\n1. change `IS_RULE_SPECIFIC_FLAPPING_ENABLED` to true
\r\n2. run `yarn start --run-examples`\r\n3. assert the new flapping UI
exists by going to developer examples ->\r\ncreate/edit rule\r\n\r\n<img
width=\"1162\" alt=\"Screenshot 2024-09-30 at 11 43
16 PM\"\r\nsrc=\"https://github.com/user-attachments/assets/a1275a49-f2ed-43ce-815b-5c0bd93770e5\">\r\n\r\n###
Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"447617e2be18cbf8fdd495cb4b9570921b7fd467"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Jiawei Wu <74562234+JiaweiWu@users.noreply.github.com>
2024-10-10 05:47:55 +02:00
Kibana Machine
b44b90d3a8
[8.x] [Response Ops][Alerting] Refactor &#x60;ExecutionHandler&#x60; stage 2 (#193807) (#195676)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Alerting] Refactor &#x60;ExecutionHandler&#x60; stage
2 (#193807)](https://github.com/elastic/kibana/pull/193807)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Ying
Mao","email":"ying.mao@elastic.co"},"sourceCommit":{"committedDate":"2024-10-09T21:01:16Z","message":"[Response
Ops][Alerting] Refactor `ExecutionHandler` stage 2 (#193807)\n\nResolves
https://github.com/elastic/kibana/issues/186534\r\n\r\n##
Summary\r\n\r\nThis PR splits the for-loop in the `ActionScheduler.run`
function into\r\nthe appropriate scheduler classes. Previously, each
scheduler had a\r\n`generateExecutables` function that would return an
array of executables\r\nand the `ActionScheduler` would loop through the
array and convert the\r\nexecutable to a scheduleable action depending
on whether it was a\r\nper-alert action, summary action or system
action. This refactor renames\r\n`generateExecutables` into
`getActionsToSchedule` and moves the logic to\r\nconvert the executables
into a schedulable action into the appropriate\r\nscheduler
class.\r\n\r\n## To Verify\r\n\r\nCreate some rules with per-alert and
summary and system actions and\r\nverify they are triggered as
expected.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"9221ab19e86ca7d3215205110fc709f7ba4739af","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[Response
Ops][Alerting] Refactor `ExecutionHandler` stage
2","number":193807,"url":"https://github.com/elastic/kibana/pull/193807","mergeCommit":{"message":"[Response
Ops][Alerting] Refactor `ExecutionHandler` stage 2 (#193807)\n\nResolves
https://github.com/elastic/kibana/issues/186534\r\n\r\n##
Summary\r\n\r\nThis PR splits the for-loop in the `ActionScheduler.run`
function into\r\nthe appropriate scheduler classes. Previously, each
scheduler had a\r\n`generateExecutables` function that would return an
array of executables\r\nand the `ActionScheduler` would loop through the
array and convert the\r\nexecutable to a scheduleable action depending
on whether it was a\r\nper-alert action, summary action or system
action. This refactor renames\r\n`generateExecutables` into
`getActionsToSchedule` and moves the logic to\r\nconvert the executables
into a schedulable action into the appropriate\r\nscheduler
class.\r\n\r\n## To Verify\r\n\r\nCreate some rules with per-alert and
summary and system actions and\r\nverify they are triggered as
expected.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"9221ab19e86ca7d3215205110fc709f7ba4739af"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/193807","number":193807,"mergeCommit":{"message":"[Response
Ops][Alerting] Refactor `ExecutionHandler` stage 2 (#193807)\n\nResolves
https://github.com/elastic/kibana/issues/186534\r\n\r\n##
Summary\r\n\r\nThis PR splits the for-loop in the `ActionScheduler.run`
function into\r\nthe appropriate scheduler classes. Previously, each
scheduler had a\r\n`generateExecutables` function that would return an
array of executables\r\nand the `ActionScheduler` would loop through the
array and convert the\r\nexecutable to a scheduleable action depending
on whether it was a\r\nper-alert action, summary action or system
action. This refactor renames\r\n`generateExecutables` into
`getActionsToSchedule` and moves the logic to\r\nconvert the executables
into a schedulable action into the appropriate\r\nscheduler
class.\r\n\r\n## To Verify\r\n\r\nCreate some rules with per-alert and
summary and system actions and\r\nverify they are triggered as
expected.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"9221ab19e86ca7d3215205110fc709f7ba4739af"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Ying Mao <ying.mao@elastic.co>
2024-10-10 01:15:45 +02:00
Kibana Machine
a02cb35f39
[8.x] [EDR Workflows] Enable response actions in base rule params (#194796) (#195611)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[EDR Workflows] Enable response actions in base rule params
(#194796)](https://github.com/elastic/kibana/pull/194796)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Tomasz
Ciecierski","email":"tomasz.ciecierski@elastic.co"},"sourceCommit":{"committedDate":"2024-10-09T14:06:02Z","message":"[EDR
Workflows] Enable response actions in base rule params
(#194796)","sha":"c103d2d21452f6c73b79036c5d10a24c018e1831","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","Team:Defend
Workflows","v8.16.0","backport:version"],"title":"[EDR Workflows] Enable
response actions in base rule
params","number":194796,"url":"https://github.com/elastic/kibana/pull/194796","mergeCommit":{"message":"[EDR
Workflows] Enable response actions in base rule params
(#194796)","sha":"c103d2d21452f6c73b79036c5d10a24c018e1831"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/194796","number":194796,"mergeCommit":{"message":"[EDR
Workflows] Enable response actions in base rule params
(#194796)","sha":"c103d2d21452f6c73b79036c5d10a24c018e1831"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Tomasz Ciecierski <tomasz.ciecierski@elastic.co>
2024-10-09 17:59:46 +02:00
Kibana Machine
8f9f106606
[8.x] [Response Ops][Flapping] Rule Specific Flapping - Create/Update API changes (#190019) (#195526)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Flapping] Rule Specific Flapping - Create/Update API
changes (#190019)](https://github.com/elastic/kibana/pull/190019)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Jiawei
Wu","email":"74562234+JiaweiWu@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-09T01:01:45Z","message":"[Response
Ops][Flapping] Rule Specific Flapping - Create/Update API changes
(#190019)\n\n## Summary\r\nIssue:
https://github.com/elastic/kibana/issues/190018\r\n\r\nImplement rule
specific flapping support for create and update Rule API.\r\nThe new
property on the rule is named `flapping`;\r\n\r\n```\r\nflapping: {\r\n
look_back_window: number;\r\n status_change_threshold:
number;\r\n}\r\n```\r\n\r\nAlso make changes in the task runner to use
the rule's flapping settings\r\nif it exists. Otherwise use the global
flapping setting.\r\n\r\n# To test\r\n1. Go
to\r\n`x-pack/plugins/triggers_actions_ui/public/common/constants/index.ts`\r\nand
turn `IS_RULE_SPECIFIC_FLAPPING_ENABLED` to `true`\r\n2. Create a rule
with a rule specific flapping setting, generate the\r\nalert and let it
flap\r\n3. Assert that the flapping is now using the rule specific
flapping\r\n4. Turn space flapping off\r\n5. Assert that it no longer
flaps despite having a rule specific\r\nflapping\r\n6. Try
deleting/adding back the rule specific flapping via the UI and\r\nverify
everything works.\r\n\r\n### Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"edd61f63dbad99fe8da1e503c81db774fcb37e8f","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[Response
Ops][Flapping] Rule Specific Flapping - Create/Update API
changes","number":190019,"url":"https://github.com/elastic/kibana/pull/190019","mergeCommit":{"message":"[Response
Ops][Flapping] Rule Specific Flapping - Create/Update API changes
(#190019)\n\n## Summary\r\nIssue:
https://github.com/elastic/kibana/issues/190018\r\n\r\nImplement rule
specific flapping support for create and update Rule API.\r\nThe new
property on the rule is named `flapping`;\r\n\r\n```\r\nflapping: {\r\n
look_back_window: number;\r\n status_change_threshold:
number;\r\n}\r\n```\r\n\r\nAlso make changes in the task runner to use
the rule's flapping settings\r\nif it exists. Otherwise use the global
flapping setting.\r\n\r\n# To test\r\n1. Go
to\r\n`x-pack/plugins/triggers_actions_ui/public/common/constants/index.ts`\r\nand
turn `IS_RULE_SPECIFIC_FLAPPING_ENABLED` to `true`\r\n2. Create a rule
with a rule specific flapping setting, generate the\r\nalert and let it
flap\r\n3. Assert that the flapping is now using the rule specific
flapping\r\n4. Turn space flapping off\r\n5. Assert that it no longer
flaps despite having a rule specific\r\nflapping\r\n6. Try
deleting/adding back the rule specific flapping via the UI and\r\nverify
everything works.\r\n\r\n### Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"edd61f63dbad99fe8da1e503c81db774fcb37e8f"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/190019","number":190019,"mergeCommit":{"message":"[Response
Ops][Flapping] Rule Specific Flapping - Create/Update API changes
(#190019)\n\n## Summary\r\nIssue:
https://github.com/elastic/kibana/issues/190018\r\n\r\nImplement rule
specific flapping support for create and update Rule API.\r\nThe new
property on the rule is named `flapping`;\r\n\r\n```\r\nflapping: {\r\n
look_back_window: number;\r\n status_change_threshold:
number;\r\n}\r\n```\r\n\r\nAlso make changes in the task runner to use
the rule's flapping settings\r\nif it exists. Otherwise use the global
flapping setting.\r\n\r\n# To test\r\n1. Go
to\r\n`x-pack/plugins/triggers_actions_ui/public/common/constants/index.ts`\r\nand
turn `IS_RULE_SPECIFIC_FLAPPING_ENABLED` to `true`\r\n2. Create a rule
with a rule specific flapping setting, generate the\r\nalert and let it
flap\r\n3. Assert that the flapping is now using the rule specific
flapping\r\n4. Turn space flapping off\r\n5. Assert that it no longer
flaps despite having a rule specific\r\nflapping\r\n6. Try
deleting/adding back the rule specific flapping via the UI and\r\nverify
everything works.\r\n\r\n### Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"edd61f63dbad99fe8da1e503c81db774fcb37e8f"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Jiawei Wu <74562234+JiaweiWu@users.noreply.github.com>
2024-10-09 04:47:24 +02:00
Kibana Machine
c3012d8ff8
[8.x] [ResponseOps][Alerting] Error when submit rule form when using AddFilterPopover in actions (#194600) (#195228)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[ResponseOps][Alerting] Error when submit rule form when using
AddFilterPopover in actions
(#194600)](https://github.com/elastic/kibana/pull/194600)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT
[{"author":{"name":"Julia","email":"iuliia.guskova@elastic.co"},"sourceCommit":{"committedDate":"2024-10-07T11:23:25Z","message":"[ResponseOps][Alerting]
Error when submit rule form when using AddFilterPopover in actions
(#194600)\n\nResolve:
https://github.com/elastic/kibana/issues/192847\r\n\r\nWhen user try to
save the rule which has a conditional action with a\r\nfilter which
contains AND or OR, it'll fail.\r\nError raises when a new rule SO
object is going to be created.\r\nValidation fails because schema is
wrong.\r\nI fixed it in this PR.\r\n\r\n\r\n### Checklist\r\n\r\n- [x]
[Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n\r\n### How
to test\r\n\r\n1. Go to Rules and try creating a new rule of any
type\r\n2. Add an action to the rule\r\n3. Check the option If alert
matches a query\r\n4. Click the + icon to add a filter\r\n5. Create a
filter in the popover\r\n6. Click AND or OR\r\n7. Create another
filter\r\n8. Click Add filter\r\n9. Try saving the rule\r\n10. Saving
should be
successful","sha":"02d0c9852f0efb15b67c06e240e1525220a701ec","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","backport","Feature:Alerting","release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[ResponseOps][Alerting]
Error when submit rule form when using AddFilterPopover in
actions","number":194600,"url":"https://github.com/elastic/kibana/pull/194600","mergeCommit":{"message":"[ResponseOps][Alerting]
Error when submit rule form when using AddFilterPopover in actions
(#194600)\n\nResolve:
https://github.com/elastic/kibana/issues/192847\r\n\r\nWhen user try to
save the rule which has a conditional action with a\r\nfilter which
contains AND or OR, it'll fail.\r\nError raises when a new rule SO
object is going to be created.\r\nValidation fails because schema is
wrong.\r\nI fixed it in this PR.\r\n\r\n\r\n### Checklist\r\n\r\n- [x]
[Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n\r\n### How
to test\r\n\r\n1. Go to Rules and try creating a new rule of any
type\r\n2. Add an action to the rule\r\n3. Check the option If alert
matches a query\r\n4. Click the + icon to add a filter\r\n5. Create a
filter in the popover\r\n6. Click AND or OR\r\n7. Create another
filter\r\n8. Click Add filter\r\n9. Try saving the rule\r\n10. Saving
should be
successful","sha":"02d0c9852f0efb15b67c06e240e1525220a701ec"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/194600","number":194600,"mergeCommit":{"message":"[ResponseOps][Alerting]
Error when submit rule form when using AddFilterPopover in actions
(#194600)\n\nResolve:
https://github.com/elastic/kibana/issues/192847\r\n\r\nWhen user try to
save the rule which has a conditional action with a\r\nfilter which
contains AND or OR, it'll fail.\r\nError raises when a new rule SO
object is going to be created.\r\nValidation fails because schema is
wrong.\r\nI fixed it in this PR.\r\n\r\n\r\n### Checklist\r\n\r\n- [x]
[Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n\r\n### How
to test\r\n\r\n1. Go to Rules and try creating a new rule of any
type\r\n2. Add an action to the rule\r\n3. Check the option If alert
matches a query\r\n4. Click the + icon to add a filter\r\n5. Create a
filter in the popover\r\n6. Click AND or OR\r\n7. Create another
filter\r\n8. Click Add filter\r\n9. Try saving the rule\r\n10. Saving
should be
successful","sha":"02d0c9852f0efb15b67c06e240e1525220a701ec"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Julia <iuliia.guskova@elastic.co>
2024-10-07 08:11:49 -05:00
Kibana Machine
c9178334a7
[8.x] [ResponseOps][Telemetry] Add default value for new telemetry fields for old tasks (#194827) (#195140)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[ResponseOps][Telemetry] Add default value for new telemetry fields
for old tasks (#194827)](https://github.com/elastic/kibana/pull/194827)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT
[{"author":{"name":"Julia","email":"iuliia.guskova@elastic.co"},"sourceCommit":{"committedDate":"2024-10-04T18:51:54Z","message":"[ResponseOps][Telemetry]
Add default value for new telemetry fields for old tasks
(#194827)\n\nSolve:
https://github.com/elastic/kibana/issues/194717\r\n\r\nWhen we add new
fields to telemetry, we forgot to add them to this\r\nplace, which for
tasks that were created < 8.10 will go migration.\r\nProbably serverless
has some old tasks. Probably because of it task run\r\nfails. So I fix
it
here.","sha":"38abda52bb9af156be245b3ffc1a8ea93e58fe12","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[ResponseOps][Telemetry]
Add default value for new telemetry fields for old
tasks","number":194827,"url":"https://github.com/elastic/kibana/pull/194827","mergeCommit":{"message":"[ResponseOps][Telemetry]
Add default value for new telemetry fields for old tasks
(#194827)\n\nSolve:
https://github.com/elastic/kibana/issues/194717\r\n\r\nWhen we add new
fields to telemetry, we forgot to add them to this\r\nplace, which for
tasks that were created < 8.10 will go migration.\r\nProbably serverless
has some old tasks. Probably because of it task run\r\nfails. So I fix
it
here.","sha":"38abda52bb9af156be245b3ffc1a8ea93e58fe12"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/194827","number":194827,"mergeCommit":{"message":"[ResponseOps][Telemetry]
Add default value for new telemetry fields for old tasks
(#194827)\n\nSolve:
https://github.com/elastic/kibana/issues/194717\r\n\r\nWhen we add new
fields to telemetry, we forgot to add them to this\r\nplace, which for
tasks that were created < 8.10 will go migration.\r\nProbably serverless
has some old tasks. Probably because of it task run\r\nfails. So I fix
it
here.","sha":"38abda52bb9af156be245b3ffc1a8ea93e58fe12"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Julia <iuliia.guskova@elastic.co>
2024-10-04 15:40:45 -05:00
Kibana Machine
23e1bdf32e
[8.x] [Response Ops][Alerting] Remove rules client from alerting task runner (#194300) (#194858)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Alerting] Remove rules client from alerting task
runner (#194300)](https://github.com/elastic/kibana/pull/194300)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Ying
Mao","email":"ying.mao@elastic.co"},"sourceCommit":{"committedDate":"2024-10-03T15:53:06Z","message":"[Response
Ops][Alerting] Remove rules client from alerting task runner
(#194300)\n\n## Summary\r\n\r\nInitializing the rules client with every
rule execution causes 2\r\nrequests to Elasticsearch, a `POST
/_security/user/_has_privileges`\r\nrequest and a
`GET/.kibana_<version>/_doc/space:<spaceId>` request. We\r\nonly use the
rules client to proxy two methods `getAlertFromRaw`
and\r\n`clearExpiredSnoozes`. Both of these methods can be converted
into\r\nlibrary functions that can be used without the rules client.
This PR\r\nmakes that
conversion.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"326f81398472e160fec254c05541aa2a588a7f70","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[Response
Ops][Alerting] Remove rules client from alerting task
runner","number":194300,"url":"https://github.com/elastic/kibana/pull/194300","mergeCommit":{"message":"[Response
Ops][Alerting] Remove rules client from alerting task runner
(#194300)\n\n## Summary\r\n\r\nInitializing the rules client with every
rule execution causes 2\r\nrequests to Elasticsearch, a `POST
/_security/user/_has_privileges`\r\nrequest and a
`GET/.kibana_<version>/_doc/space:<spaceId>` request. We\r\nonly use the
rules client to proxy two methods `getAlertFromRaw`
and\r\n`clearExpiredSnoozes`. Both of these methods can be converted
into\r\nlibrary functions that can be used without the rules client.
This PR\r\nmakes that
conversion.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"326f81398472e160fec254c05541aa2a588a7f70"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/194300","number":194300,"mergeCommit":{"message":"[Response
Ops][Alerting] Remove rules client from alerting task runner
(#194300)\n\n## Summary\r\n\r\nInitializing the rules client with every
rule execution causes 2\r\nrequests to Elasticsearch, a `POST
/_security/user/_has_privileges`\r\nrequest and a
`GET/.kibana_<version>/_doc/space:<spaceId>` request. We\r\nonly use the
rules client to proxy two methods `getAlertFromRaw`
and\r\n`clearExpiredSnoozes`. Both of these methods can be converted
into\r\nlibrary functions that can be used without the rules client.
This PR\r\nmakes that
conversion.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"326f81398472e160fec254c05541aa2a588a7f70"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Ying Mao <ying.mao@elastic.co>
2024-10-03 12:37:16 -05:00
Kibana Machine
2ac2f9a27e
[8.x] Remove max limit of alerting.rules.maxScheduledPerMinute (#194723) (#194826)
# Backport

This will backport the following commits from `main` to `8.x`:
- [Remove max limit of alerting.rules.maxScheduledPerMinute
(#194723)](https://github.com/elastic/kibana/pull/194723)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Ersin
Erdal","email":"92688503+ersin-erdal@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-03T12:11:10Z","message":"Remove
max limit of alerting.rules.maxScheduledPerMinute (#194723)\n\nResolves:
#194626\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"7d29cb1a77f9a0c284d0b66d723d054460b512e7","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"Remove
max limit of
alerting.rules.maxScheduledPerMinute","number":194723,"url":"https://github.com/elastic/kibana/pull/194723","mergeCommit":{"message":"Remove
max limit of alerting.rules.maxScheduledPerMinute (#194723)\n\nResolves:
#194626\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"7d29cb1a77f9a0c284d0b66d723d054460b512e7"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/194723","number":194723,"mergeCommit":{"message":"Remove
max limit of alerting.rules.maxScheduledPerMinute (#194723)\n\nResolves:
#194626\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"7d29cb1a77f9a0c284d0b66d723d054460b512e7"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Ersin Erdal <92688503+ersin-erdal@users.noreply.github.com>
2024-10-03 08:51:01 -05:00
Shahzad
757e9199cf
[8.x] [Synthetics] Improve synthetics alerting (#186585) (#194671)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Synthetics] Improve synthetics alerting
(#186585)](https://github.com/elastic/kibana/pull/186585)

<!--- Backport version: 8.9.8 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT
[{"author":{"name":"Shahzad","email":"shahzad31comp@gmail.com"},"sourceCommit":{"committedDate":"2024-10-01T16:48:39Z","message":"[Synthetics]
Improve synthetics alerting (#186585)\n\n## Summary\r\n\r\nFixes
https://github.com/elastic/kibana/issues/175298\r\n\r\nImprove
synthetics alerting !!\r\n\r\nUser will be able to create custom
synthetics status alert by defining\r\nthree kind of criteria\r\n\r\n###
Monitor is down over last consective checks with threshold\r\n\r\n<img
width=\"639\"
alt=\"image\"\r\nsrc=\"390da238-f7f2-4eb0-9606-3279b3199fdf\">\r\n\r\n###
From Locations threshold\r\n\r\nWill be considered down only when from
defined number of locations\r\n\r\n<img width=\"618\"
alt=\"image\"\r\nsrc=\"24741a10-0880-4247-9048-8ce03df25bf5\">\r\n\r\n\r\n###
Over time with checks threshold just like uptime custom status
alert\r\n\r\n<img width=\"631\"
alt=\"image\"\r\nsrc=\"64e1c808-8d4b-4dd0-b794-eb7f4e5d1e6b\">\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Dominique Clarke <dominique.clarke@elastic.co>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by: Maryam
Saeidi <maryam.saeidi@elastic.co>\r\nCo-authored-by: Justin Kambic
<jk@elastic.co>","sha":"82d0b008cdc4f9bcfe3bc858b15d6d30e91fed89","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:enhancement","v9.0.0","release_note:feature","backport:prev-minor","ci:project-deploy-observability","Team:obs-ux-management"],"number":186585,"url":"https://github.com/elastic/kibana/pull/186585","mergeCommit":{"message":"[Synthetics]
Improve synthetics alerting (#186585)\n\n## Summary\r\n\r\nFixes
https://github.com/elastic/kibana/issues/175298\r\n\r\nImprove
synthetics alerting !!\r\n\r\nUser will be able to create custom
synthetics status alert by defining\r\nthree kind of criteria\r\n\r\n###
Monitor is down over last consective checks with threshold\r\n\r\n<img
width=\"639\"
alt=\"image\"\r\nsrc=\"390da238-f7f2-4eb0-9606-3279b3199fdf\">\r\n\r\n###
From Locations threshold\r\n\r\nWill be considered down only when from
defined number of locations\r\n\r\n<img width=\"618\"
alt=\"image\"\r\nsrc=\"24741a10-0880-4247-9048-8ce03df25bf5\">\r\n\r\n\r\n###
Over time with checks threshold just like uptime custom status
alert\r\n\r\n<img width=\"631\"
alt=\"image\"\r\nsrc=\"64e1c808-8d4b-4dd0-b794-eb7f4e5d1e6b\">\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Dominique Clarke <dominique.clarke@elastic.co>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by: Maryam
Saeidi <maryam.saeidi@elastic.co>\r\nCo-authored-by: Justin Kambic
<jk@elastic.co>","sha":"82d0b008cdc4f9bcfe3bc858b15d6d30e91fed89"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/186585","number":186585,"mergeCommit":{"message":"[Synthetics]
Improve synthetics alerting (#186585)\n\n## Summary\r\n\r\nFixes
https://github.com/elastic/kibana/issues/175298\r\n\r\nImprove
synthetics alerting !!\r\n\r\nUser will be able to create custom
synthetics status alert by defining\r\nthree kind of criteria\r\n\r\n###
Monitor is down over last consective checks with threshold\r\n\r\n<img
width=\"639\"
alt=\"image\"\r\nsrc=\"390da238-f7f2-4eb0-9606-3279b3199fdf\">\r\n\r\n###
From Locations threshold\r\n\r\nWill be considered down only when from
defined number of locations\r\n\r\n<img width=\"618\"
alt=\"image\"\r\nsrc=\"24741a10-0880-4247-9048-8ce03df25bf5\">\r\n\r\n\r\n###
Over time with checks threshold just like uptime custom status
alert\r\n\r\n<img width=\"631\"
alt=\"image\"\r\nsrc=\"64e1c808-8d4b-4dd0-b794-eb7f4e5d1e6b\">\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Dominique Clarke <dominique.clarke@elastic.co>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by: Maryam
Saeidi <maryam.saeidi@elastic.co>\r\nCo-authored-by: Justin Kambic
<jk@elastic.co>","sha":"82d0b008cdc4f9bcfe3bc858b15d6d30e91fed89"}}]}]
BACKPORT-->
2024-10-02 11:26:49 -05:00
Kibana Machine
ce42c68ccd
[8.x] [Response Ops][Alerting] Use ES client to update rule SO at end of rule run instead of SO client. (#193341) (#194444)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Alerting] Use ES client to update rule SO at end of
rule run instead of SO client.
(#193341)](https://github.com/elastic/kibana/pull/193341)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Ying
Mao","email":"ying.mao@elastic.co"},"sourceCommit":{"committedDate":"2024-09-30T14:40:02Z","message":"[Response
Ops][Alerting] Use ES client to update rule SO at end of rule run
instead of SO client. (#193341)\n\nResolves
https://github.com/elastic/kibana/issues/192397\r\n\r\n##
Summary\r\n\r\nUpdates alerting task runner end of run updates to use
the ES client\r\nupdate function for a true partial update instead of
the saved objects\r\nclient update function that performs a GET then an
update.\r\n\r\n## To verify\r\nCreate a rule in multiple spaces and
ensure they run correctly and their\r\nexecution status and monitoring
history are updated at the end of each\r\nrun. Because we're performing
a partial update on attributes that are\r\nnot in the AAD, the rule
should continue running without any encryption\r\nerrors.\r\n\r\n## Risk
Matrix\r\n\r\n| Risk | Probability | Severity | Mitigation/Notes
|\r\n\r\n|---------------------------|-------------|----------|-------------------------|\r\n|
Updating saved object directly using ES client will break BWC |
Medium\r\n| High | Response Ops follows an intermediate release strategy
for any\r\nchanges to the rule saved object where schema changes are
introduced in\r\nan intermediate release before any changes to the saved
object are\r\nactually made in a followup release. This ensures that any
rollbacks\r\nthat may be required in a release will roll back to a
version that is\r\nalready aware of the new schema. The team is
socialized to this strategy\r\nas we are requiring users of the alerting
framework to also follow this\r\nstrategy. This should address any
backward compatibility issues that\r\nmight arise by circumventing the
saved objects client update function. |\r\n| Updating saved object
directly using ES client will break AAD | Medium\r\n| High | An explicit
allowlist of non-AAD fields that are allowed to be\r\npartially updated
has been introduced and any fields not in this\r\nallowlist will not be
included in the partial update. Any updates to the\r\nrule saved object
that might break AAD would show up with > 1 execution\r\nof a rule and
we have a plethora of functional tests that rely on\r\nmultiple
executions of a rule that would flag if there were issues\r\nrunning due
to AAD issues. |\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"05926c20c57b7abc69c6c068d5733f29306f73ba","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[Response
Ops][Alerting] Use ES client to update rule SO at end of rule run
instead of SO
client.","number":193341,"url":"https://github.com/elastic/kibana/pull/193341","mergeCommit":{"message":"[Response
Ops][Alerting] Use ES client to update rule SO at end of rule run
instead of SO client. (#193341)\n\nResolves
https://github.com/elastic/kibana/issues/192397\r\n\r\n##
Summary\r\n\r\nUpdates alerting task runner end of run updates to use
the ES client\r\nupdate function for a true partial update instead of
the saved objects\r\nclient update function that performs a GET then an
update.\r\n\r\n## To verify\r\nCreate a rule in multiple spaces and
ensure they run correctly and their\r\nexecution status and monitoring
history are updated at the end of each\r\nrun. Because we're performing
a partial update on attributes that are\r\nnot in the AAD, the rule
should continue running without any encryption\r\nerrors.\r\n\r\n## Risk
Matrix\r\n\r\n| Risk | Probability | Severity | Mitigation/Notes
|\r\n\r\n|---------------------------|-------------|----------|-------------------------|\r\n|
Updating saved object directly using ES client will break BWC |
Medium\r\n| High | Response Ops follows an intermediate release strategy
for any\r\nchanges to the rule saved object where schema changes are
introduced in\r\nan intermediate release before any changes to the saved
object are\r\nactually made in a followup release. This ensures that any
rollbacks\r\nthat may be required in a release will roll back to a
version that is\r\nalready aware of the new schema. The team is
socialized to this strategy\r\nas we are requiring users of the alerting
framework to also follow this\r\nstrategy. This should address any
backward compatibility issues that\r\nmight arise by circumventing the
saved objects client update function. |\r\n| Updating saved object
directly using ES client will break AAD | Medium\r\n| High | An explicit
allowlist of non-AAD fields that are allowed to be\r\npartially updated
has been introduced and any fields not in this\r\nallowlist will not be
included in the partial update. Any updates to the\r\nrule saved object
that might break AAD would show up with > 1 execution\r\nof a rule and
we have a plethora of functional tests that rely on\r\nmultiple
executions of a rule that would flag if there were issues\r\nrunning due
to AAD issues. |\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"05926c20c57b7abc69c6c068d5733f29306f73ba"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/193341","number":193341,"mergeCommit":{"message":"[Response
Ops][Alerting] Use ES client to update rule SO at end of rule run
instead of SO client. (#193341)\n\nResolves
https://github.com/elastic/kibana/issues/192397\r\n\r\n##
Summary\r\n\r\nUpdates alerting task runner end of run updates to use
the ES client\r\nupdate function for a true partial update instead of
the saved objects\r\nclient update function that performs a GET then an
update.\r\n\r\n## To verify\r\nCreate a rule in multiple spaces and
ensure they run correctly and their\r\nexecution status and monitoring
history are updated at the end of each\r\nrun. Because we're performing
a partial update on attributes that are\r\nnot in the AAD, the rule
should continue running without any encryption\r\nerrors.\r\n\r\n## Risk
Matrix\r\n\r\n| Risk | Probability | Severity | Mitigation/Notes
|\r\n\r\n|---------------------------|-------------|----------|-------------------------|\r\n|
Updating saved object directly using ES client will break BWC |
Medium\r\n| High | Response Ops follows an intermediate release strategy
for any\r\nchanges to the rule saved object where schema changes are
introduced in\r\nan intermediate release before any changes to the saved
object are\r\nactually made in a followup release. This ensures that any
rollbacks\r\nthat may be required in a release will roll back to a
version that is\r\nalready aware of the new schema. The team is
socialized to this strategy\r\nas we are requiring users of the alerting
framework to also follow this\r\nstrategy. This should address any
backward compatibility issues that\r\nmight arise by circumventing the
saved objects client update function. |\r\n| Updating saved object
directly using ES client will break AAD | Medium\r\n| High | An explicit
allowlist of non-AAD fields that are allowed to be\r\npartially updated
has been introduced and any fields not in this\r\nallowlist will not be
included in the partial update. Any updates to the\r\nrule saved object
that might break AAD would show up with > 1 execution\r\nof a rule and
we have a plethora of functional tests that rely on\r\nmultiple
executions of a rule that would flag if there were issues\r\nrunning due
to AAD issues. |\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"05926c20c57b7abc69c6c068d5733f29306f73ba"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Ying Mao <ying.mao@elastic.co>
2024-09-30 11:33:28 -05:00
Kibana Machine
464430dd87
[8.x] [ResponseOps][Alerts] Fix authorization issues with &#x60;discover&#x60; as consumers (#192321) (#194441)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[ResponseOps][Alerts] Fix authorization issues with
&#x60;discover&#x60; as consumers
(#192321)](https://github.com/elastic/kibana/pull/192321)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Christos
Nasikas","email":"christos.nasikas@elastic.co"},"sourceCommit":{"committedDate":"2024-09-30T14:11:00Z","message":"[ResponseOps][Alerts]
Fix authorization issues with `discover` as consumers (#192321)\n\n##
Summary\r\n\r\nAlerts use its own RBAC model. The RBAC relies on a
property called\r\n`consumer`. The consumer is tight coupled with the
feature ID. It\r\ndenotes the user's access to the rule and the alerts.
For example, a\r\nuser with access to the \"Logs\" feature has access
only to alerts and\r\nrules with the `consumer` set as `logs`. Users can
create an ES Query\r\nrule from Discover. When the feature
was\r\n[implemented](https://github.com/elastic/kibana/pull/124534)
(v8.3.0)\r\nthe consumer was set to `discover`. Then
it\r\n[changed](https://github.com/elastic/kibana/pull/166032) (v8.11.0)
to\r\n`stackAlerts` (visible only on the stack management page) and
then\r\n[to](https://github.com/elastic/kibana/pull/171364) (v8.12.0)
`alerts`\r\nso it can be visible in Observability. Users who created
rules that\r\ngenerated alerts with the `discover` consumer cannot see
the alerts\r\ngenerated by the rule when they upgrade Kibana to 8.11+
even as\r\nsuperusers. This PR fixes the issues around the `discover`
consumer.\r\n\r\nI added the following alert document to the
`data.json.gz` to test for\r\nalerts with `discover`
consumer.\r\n\r\n```\r\n{\r\n \"type\": \"doc\",\r\n \"value\": {\r\n
\"id\": \"1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97\",\r\n \"index\":
\".internal.alerts-stack.alerts-default-000001\",\r\n \"source\": {\r\n
\"@timestamp\": \"2021-10-19T14:00:38.749Z\",\r\n \"event.action\":
\"active\",\r\n \"event.kind\": \"signal\",\r\n
\"kibana.alert.duration.us\": 1370302000,\r\n
\"kibana.alert.evaluation.threshold\": -1,\r\n
\"kibana.alert.evaluation.value\": 80,\r\n \"kibana.alert.instance.id\":
\"query matched\",\r\n \"kibana.alert.reason\": \"Document count is 80
in the last 100d in .kibana_alerting_cases index. Alert when greater
than -1.\",\r\n \"kibana.alert.rule.category\": \"Elasticsearch
query\",\r\n \"kibana.alert.rule.consumer\": \"discover\",\r\n
\"kibana.alert.rule.name\": \"EsQuery discover\",\r\n
\"kibana.alert.rule.producer\": \"stackAlerts\",\r\n
\"kibana.alert.rule.rule_type_id\": \".es-query\",\r\n
\"kibana.alert.rule.uuid\":
\"25c14920-faa7-4a9a-830c-ce32c8211237\",\r\n \"kibana.alert.start\":
\"2021-10-19T15:00:41.555Z\",\r\n \"kibana.alert.status\":
\"active\",\r\n \"kibana.alert.time_range\": {\r\n \"gte\":
\"2021-10-19T15:00:41.555Z\"\r\n },\r\n \"kibana.alert.uuid\":
\"23237979-75bf-4b68-a210-ce5056b93356\",\r\n
\"kibana.alert.workflow_status\": \"open\",\r\n \"kibana.space_ids\":
[\r\n \"default\"\r\n ],\r\n \"kibana.version\": \"8.0.0\",\r\n
\"tags\": []\r\n }\r\n }\r\n}\r\n```\r\n\r\n## Testing\r\n\r\n1. Create
a rule with the consumer as `discover`.
See\r\nhttps://github.com/elastic/kibana/issues/184595 for
instructions.\r\n2. Go to the rule details page.\r\n3. Verify that you
do not get any error toaster and you can see
the\r\nalerts.\r\n\r\nFixes:
https://github.com/elastic/kibana/issues/184595\r\n\r\n###
Checklist\r\n\r\nDelete any items that are not applicable to this
PR.\r\n\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n### For
maintainers\r\n\r\n- [x] This was checked for breaking API changes and
was
[labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n##
Release notes\r\nFix an issue with rules not being accessible created
from Discover\r\nbefore 8.11.0.\r\n\r\n---------\r\n\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"396931f5056600e633dba64dab81a66096d05f72","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:fix","Feature:Alerting","Team:ResponseOps","v9.0.0","Feature:Alerting/RulesFramework","backport:prev-major","v8.16.0","v8.15.3"],"title":"[ResponseOps][Alerts]
Fix authorization issues with `discover` as
consumers","number":192321,"url":"https://github.com/elastic/kibana/pull/192321","mergeCommit":{"message":"[ResponseOps][Alerts]
Fix authorization issues with `discover` as consumers (#192321)\n\n##
Summary\r\n\r\nAlerts use its own RBAC model. The RBAC relies on a
property called\r\n`consumer`. The consumer is tight coupled with the
feature ID. It\r\ndenotes the user's access to the rule and the alerts.
For example, a\r\nuser with access to the \"Logs\" feature has access
only to alerts and\r\nrules with the `consumer` set as `logs`. Users can
create an ES Query\r\nrule from Discover. When the feature
was\r\n[implemented](https://github.com/elastic/kibana/pull/124534)
(v8.3.0)\r\nthe consumer was set to `discover`. Then
it\r\n[changed](https://github.com/elastic/kibana/pull/166032) (v8.11.0)
to\r\n`stackAlerts` (visible only on the stack management page) and
then\r\n[to](https://github.com/elastic/kibana/pull/171364) (v8.12.0)
`alerts`\r\nso it can be visible in Observability. Users who created
rules that\r\ngenerated alerts with the `discover` consumer cannot see
the alerts\r\ngenerated by the rule when they upgrade Kibana to 8.11+
even as\r\nsuperusers. This PR fixes the issues around the `discover`
consumer.\r\n\r\nI added the following alert document to the
`data.json.gz` to test for\r\nalerts with `discover`
consumer.\r\n\r\n```\r\n{\r\n \"type\": \"doc\",\r\n \"value\": {\r\n
\"id\": \"1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97\",\r\n \"index\":
\".internal.alerts-stack.alerts-default-000001\",\r\n \"source\": {\r\n
\"@timestamp\": \"2021-10-19T14:00:38.749Z\",\r\n \"event.action\":
\"active\",\r\n \"event.kind\": \"signal\",\r\n
\"kibana.alert.duration.us\": 1370302000,\r\n
\"kibana.alert.evaluation.threshold\": -1,\r\n
\"kibana.alert.evaluation.value\": 80,\r\n \"kibana.alert.instance.id\":
\"query matched\",\r\n \"kibana.alert.reason\": \"Document count is 80
in the last 100d in .kibana_alerting_cases index. Alert when greater
than -1.\",\r\n \"kibana.alert.rule.category\": \"Elasticsearch
query\",\r\n \"kibana.alert.rule.consumer\": \"discover\",\r\n
\"kibana.alert.rule.name\": \"EsQuery discover\",\r\n
\"kibana.alert.rule.producer\": \"stackAlerts\",\r\n
\"kibana.alert.rule.rule_type_id\": \".es-query\",\r\n
\"kibana.alert.rule.uuid\":
\"25c14920-faa7-4a9a-830c-ce32c8211237\",\r\n \"kibana.alert.start\":
\"2021-10-19T15:00:41.555Z\",\r\n \"kibana.alert.status\":
\"active\",\r\n \"kibana.alert.time_range\": {\r\n \"gte\":
\"2021-10-19T15:00:41.555Z\"\r\n },\r\n \"kibana.alert.uuid\":
\"23237979-75bf-4b68-a210-ce5056b93356\",\r\n
\"kibana.alert.workflow_status\": \"open\",\r\n \"kibana.space_ids\":
[\r\n \"default\"\r\n ],\r\n \"kibana.version\": \"8.0.0\",\r\n
\"tags\": []\r\n }\r\n }\r\n}\r\n```\r\n\r\n## Testing\r\n\r\n1. Create
a rule with the consumer as `discover`.
See\r\nhttps://github.com/elastic/kibana/issues/184595 for
instructions.\r\n2. Go to the rule details page.\r\n3. Verify that you
do not get any error toaster and you can see
the\r\nalerts.\r\n\r\nFixes:
https://github.com/elastic/kibana/issues/184595\r\n\r\n###
Checklist\r\n\r\nDelete any items that are not applicable to this
PR.\r\n\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n### For
maintainers\r\n\r\n- [x] This was checked for breaking API changes and
was
[labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n##
Release notes\r\nFix an issue with rules not being accessible created
from Discover\r\nbefore 8.11.0.\r\n\r\n---------\r\n\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"396931f5056600e633dba64dab81a66096d05f72"}},"sourceBranch":"main","suggestedTargetBranches":["8.x","8.15"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/192321","number":192321,"mergeCommit":{"message":"[ResponseOps][Alerts]
Fix authorization issues with `discover` as consumers (#192321)\n\n##
Summary\r\n\r\nAlerts use its own RBAC model. The RBAC relies on a
property called\r\n`consumer`. The consumer is tight coupled with the
feature ID. It\r\ndenotes the user's access to the rule and the alerts.
For example, a\r\nuser with access to the \"Logs\" feature has access
only to alerts and\r\nrules with the `consumer` set as `logs`. Users can
create an ES Query\r\nrule from Discover. When the feature
was\r\n[implemented](https://github.com/elastic/kibana/pull/124534)
(v8.3.0)\r\nthe consumer was set to `discover`. Then
it\r\n[changed](https://github.com/elastic/kibana/pull/166032) (v8.11.0)
to\r\n`stackAlerts` (visible only on the stack management page) and
then\r\n[to](https://github.com/elastic/kibana/pull/171364) (v8.12.0)
`alerts`\r\nso it can be visible in Observability. Users who created
rules that\r\ngenerated alerts with the `discover` consumer cannot see
the alerts\r\ngenerated by the rule when they upgrade Kibana to 8.11+
even as\r\nsuperusers. This PR fixes the issues around the `discover`
consumer.\r\n\r\nI added the following alert document to the
`data.json.gz` to test for\r\nalerts with `discover`
consumer.\r\n\r\n```\r\n{\r\n \"type\": \"doc\",\r\n \"value\": {\r\n
\"id\": \"1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97\",\r\n \"index\":
\".internal.alerts-stack.alerts-default-000001\",\r\n \"source\": {\r\n
\"@timestamp\": \"2021-10-19T14:00:38.749Z\",\r\n \"event.action\":
\"active\",\r\n \"event.kind\": \"signal\",\r\n
\"kibana.alert.duration.us\": 1370302000,\r\n
\"kibana.alert.evaluation.threshold\": -1,\r\n
\"kibana.alert.evaluation.value\": 80,\r\n \"kibana.alert.instance.id\":
\"query matched\",\r\n \"kibana.alert.reason\": \"Document count is 80
in the last 100d in .kibana_alerting_cases index. Alert when greater
than -1.\",\r\n \"kibana.alert.rule.category\": \"Elasticsearch
query\",\r\n \"kibana.alert.rule.consumer\": \"discover\",\r\n
\"kibana.alert.rule.name\": \"EsQuery discover\",\r\n
\"kibana.alert.rule.producer\": \"stackAlerts\",\r\n
\"kibana.alert.rule.rule_type_id\": \".es-query\",\r\n
\"kibana.alert.rule.uuid\":
\"25c14920-faa7-4a9a-830c-ce32c8211237\",\r\n \"kibana.alert.start\":
\"2021-10-19T15:00:41.555Z\",\r\n \"kibana.alert.status\":
\"active\",\r\n \"kibana.alert.time_range\": {\r\n \"gte\":
\"2021-10-19T15:00:41.555Z\"\r\n },\r\n \"kibana.alert.uuid\":
\"23237979-75bf-4b68-a210-ce5056b93356\",\r\n
\"kibana.alert.workflow_status\": \"open\",\r\n \"kibana.space_ids\":
[\r\n \"default\"\r\n ],\r\n \"kibana.version\": \"8.0.0\",\r\n
\"tags\": []\r\n }\r\n }\r\n}\r\n```\r\n\r\n## Testing\r\n\r\n1. Create
a rule with the consumer as `discover`.
See\r\nhttps://github.com/elastic/kibana/issues/184595 for
instructions.\r\n2. Go to the rule details page.\r\n3. Verify that you
do not get any error toaster and you can see
the\r\nalerts.\r\n\r\nFixes:
https://github.com/elastic/kibana/issues/184595\r\n\r\n###
Checklist\r\n\r\nDelete any items that are not applicable to this
PR.\r\n\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n### For
maintainers\r\n\r\n- [x] This was checked for breaking API changes and
was
[labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n##
Release notes\r\nFix an issue with rules not being accessible created
from Discover\r\nbefore 8.11.0.\r\n\r\n---------\r\n\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"396931f5056600e633dba64dab81a66096d05f72"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.15","label":"v8.15.3","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
2024-09-30 11:22:26 -05:00
Kibana Machine
d90b6a754c
[8.x] [DOCS][ResponseOps] Remove tech preview from ES query ES|QL rule type (#194233) (#194345)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[DOCS][ResponseOps] Remove tech preview from ES query ES|QL rule type
(#194233)](https://github.com/elastic/kibana/pull/194233)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Lisa
Cawley","email":"lcawley@elastic.co"},"sourceCommit":{"committedDate":"2024-09-27T19:45:09Z","message":"[DOCS][ResponseOps]
Remove tech preview from ES query ES|QL rule type
(#194233)","sha":"907c82da92b06f631d9bcc738bbda4db7f0f7cd8","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","v9.0.0","docs","v8.16.0","backport:version"],"title":"[DOCS][ResponseOps]
Remove tech preview from ES query ES|QL rule
type","number":194233,"url":"https://github.com/elastic/kibana/pull/194233","mergeCommit":{"message":"[DOCS][ResponseOps]
Remove tech preview from ES query ES|QL rule type
(#194233)","sha":"907c82da92b06f631d9bcc738bbda4db7f0f7cd8"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/194233","number":194233,"mergeCommit":{"message":"[DOCS][ResponseOps]
Remove tech preview from ES query ES|QL rule type
(#194233)","sha":"907c82da92b06f631d9bcc738bbda4db7f0f7cd8"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Lisa Cawley <lcawley@elastic.co>
2024-09-27 16:10:59 -05:00
Ying Mao
3358772208
[8.x] [Response Ops][Alerting] Only load maintenance windows when there are alerts during rule execution and caching loaded maintenance windows (#192573) (#194191)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Alerting] Only load maintenance windows when there are
alerts during rule execution and caching loaded maintenance windows
(#192573)](https://github.com/elastic/kibana/pull/192573)

<!--- Backport version: 8.9.8 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Ying
Mao","email":"ying.mao@elastic.co"},"sourceCommit":{"committedDate":"2024-09-26T12:59:36Z","message":"[Response
Ops][Alerting] Only load maintenance windows when there are alerts
during rule execution and caching loaded maintenance windows
(#192573)\n\nResolves
https://github.com/elastic/kibana/issues/184324\r\n\r\n##
Summary\r\n\r\nThis PR moves the loading of maintenance windows further
down in rule\r\nexecution so maintenance windows are only loaded when a
rule execution\r\ngenerates alerts. Also caches maintenance windows per
space to reduce\r\nthe number of requests.\r\n\r\n## To Verify\r\n\r\n1.
Add some logging
to\r\nx-pack/plugins/alerting/server/task_runner/maintenance_windows/maintenance_windows_service.ts\r\nto
indicate when windows are being fetched and when they're
returning\r\nfrom the cache.\r\n2. Create and run some rules in
different spaces with and without alerts\r\nto see that the maintenance
windows are only loaded when there are\r\nalerts and that the windows
are returned from the cache when the cache\r\nhas not
expired.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"93414a672c2767b035110fa2d811cc040af57727","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","ci:project-deploy-observability","Team:obs-ux-management","v8.16.0"],"number":192573,"url":"https://github.com/elastic/kibana/pull/192573","mergeCommit":{"message":"[Response
Ops][Alerting] Only load maintenance windows when there are alerts
during rule execution and caching loaded maintenance windows
(#192573)\n\nResolves
https://github.com/elastic/kibana/issues/184324\r\n\r\n##
Summary\r\n\r\nThis PR moves the loading of maintenance windows further
down in rule\r\nexecution so maintenance windows are only loaded when a
rule execution\r\ngenerates alerts. Also caches maintenance windows per
space to reduce\r\nthe number of requests.\r\n\r\n## To Verify\r\n\r\n1.
Add some logging
to\r\nx-pack/plugins/alerting/server/task_runner/maintenance_windows/maintenance_windows_service.ts\r\nto
indicate when windows are being fetched and when they're
returning\r\nfrom the cache.\r\n2. Create and run some rules in
different spaces with and without alerts\r\nto see that the maintenance
windows are only loaded when there are\r\nalerts and that the windows
are returned from the cache when the cache\r\nhas not
expired.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"93414a672c2767b035110fa2d811cc040af57727"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/192573","number":192573,"mergeCommit":{"message":"[Response
Ops][Alerting] Only load maintenance windows when there are alerts
during rule execution and caching loaded maintenance windows
(#192573)\n\nResolves
https://github.com/elastic/kibana/issues/184324\r\n\r\n##
Summary\r\n\r\nThis PR moves the loading of maintenance windows further
down in rule\r\nexecution so maintenance windows are only loaded when a
rule execution\r\ngenerates alerts. Also caches maintenance windows per
space to reduce\r\nthe number of requests.\r\n\r\n## To Verify\r\n\r\n1.
Add some logging
to\r\nx-pack/plugins/alerting/server/task_runner/maintenance_windows/maintenance_windows_service.ts\r\nto
indicate when windows are being fetched and when they're
returning\r\nfrom the cache.\r\n2. Create and run some rules in
different spaces with and without alerts\r\nto see that the maintenance
windows are only loaded when there are\r\nalerts and that the windows
are returned from the cache when the cache\r\nhas not
expired.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"93414a672c2767b035110fa2d811cc040af57727"}},{"branch":"8.x","label":"v8.16.0","labelRegex":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
2024-09-26 11:15:58 -07:00
Kibana Machine
ba9a67ef96
[8.x] [RsponseOps][Alerting] Explicitly set access to all API routes of actions, connectors, rules, alerts, and cases plugins (#193520) (#194111)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[RsponseOps][Alerting] Explicitly set access to all API routes of
actions, connectors, rules, alerts, and cases plugins
(#193520)](https://github.com/elastic/kibana/pull/193520)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Janki
Salvi","email":"117571355+js-jankisalvi@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-09-26T10:00:08Z","message":"[RsponseOps][Alerting]
Explicitly set access to all API routes of actions, connectors, rules,
alerts, and cases plugins (#193520)\n\n## Summary\r\nResolves
https://github.com/elastic/kibana/issues/192956\r\nThis PR adds \r\n-
`access: internal` option to internal routes \r\n- `access: public`
option to public routes \r\n\r\nIt which will help restrict access of
internal routes and allow users to\r\naccess all public
routes.\r\n\r\nThis PR updates api routes of following
`x-pack/plugins`\r\n- actions\r\n- alerting\r\n- cases\r\n-
rule_registry\r\n- stack_connectors\r\n-
triggers_actions_ui","sha":"9c7864309ce1c5a3d085151e3b67d1635bc558c8","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[RsponseOps][Alerting]
Explicitly set access to all API routes of actions, connectors, rules,
alerts, and cases
plugins","number":193520,"url":"https://github.com/elastic/kibana/pull/193520","mergeCommit":{"message":"[RsponseOps][Alerting]
Explicitly set access to all API routes of actions, connectors, rules,
alerts, and cases plugins (#193520)\n\n## Summary\r\nResolves
https://github.com/elastic/kibana/issues/192956\r\nThis PR adds \r\n-
`access: internal` option to internal routes \r\n- `access: public`
option to public routes \r\n\r\nIt which will help restrict access of
internal routes and allow users to\r\naccess all public
routes.\r\n\r\nThis PR updates api routes of following
`x-pack/plugins`\r\n- actions\r\n- alerting\r\n- cases\r\n-
rule_registry\r\n- stack_connectors\r\n-
triggers_actions_ui","sha":"9c7864309ce1c5a3d085151e3b67d1635bc558c8"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/193520","number":193520,"mergeCommit":{"message":"[RsponseOps][Alerting]
Explicitly set access to all API routes of actions, connectors, rules,
alerts, and cases plugins (#193520)\n\n## Summary\r\nResolves
https://github.com/elastic/kibana/issues/192956\r\nThis PR adds \r\n-
`access: internal` option to internal routes \r\n- `access: public`
option to public routes \r\n\r\nIt which will help restrict access of
internal routes and allow users to\r\naccess all public
routes.\r\n\r\nThis PR updates api routes of following
`x-pack/plugins`\r\n- actions\r\n- alerting\r\n- cases\r\n-
rule_registry\r\n- stack_connectors\r\n-
triggers_actions_ui","sha":"9c7864309ce1c5a3d085151e3b67d1635bc558c8"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Janki Salvi <117571355+js-jankisalvi@users.noreply.github.com>
2024-09-26 06:39:05 -05:00
Kibana Machine
c89dbf6550
[8.x] Total number of alerts, broken down by alerting rule types telemetry (#192866) (#194057)
# Backport

This will backport the following commits from `main` to `8.x`:
- [Total number of alerts, broken down by alerting rule types telemetry
(#192866)](https://github.com/elastic/kibana/pull/192866)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Ersin
Erdal","email":"92688503+ersin-erdal@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-09-25T18:56:03Z","message":"Total
number of alerts, broken down by alerting rule types telemetry
(#192866)\n\nResolves:
https://github.com/elastic/response-ops-team/issues/150\r\n\r\nThis PR
adds a new telemetry to the alerting plugin.\r\nThe task collects the
below data and saves in the task state.\r\n\r\n`count_alerts_total`
total alerts of all time\r\n`count_alerts_by_rule_type` total alerts of
all time by rule types\r\n\r\nNote: I tried to use the stats API as
Brandon suggested in the issue,\r\nbut it just returns the total number
of alerts.\r\nWe have to use aggregations for alerts by rule types.
Therefore I didn't\r\nuse it.\r\n\r\n## To verify:\r\n\r\n\r\n- Change
the task interval to 1m on
[this\r\nline](https://github.com/elastic/kibana/pull/192866/files#diff-014c1a7c63ade0d0f548523ef161369fdeb21c589a8112f202b8086ca23af6fdL32)\r\n-
Run Kibana\r\n- Create some rules that generates alerts.\r\n- Let them
run for a while.\r\n- Check the saved alerting telemetry in the task
state by using the\r\nbelow query.\r\n- `count_alerts_total`and
`count_alerts_by_rule_type` should be\r\npopulated\r\n\r\n```\r\nGET
/.kibana_task_manager_*/_search\r\n{\r\n \"query\": {\r\n \"term\":
{\r\n \"task.taskType\": \"alerting_telemetry\" \r\n }\r\n },\r\n
\"size\" :
1\r\n}\r\n```","sha":"5832d44767f98a625603ed27b80d2d33bb29132a","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"Total
number of alerts, broken down by alerting rule types
telemetry","number":192866,"url":"https://github.com/elastic/kibana/pull/192866","mergeCommit":{"message":"Total
number of alerts, broken down by alerting rule types telemetry
(#192866)\n\nResolves:
https://github.com/elastic/response-ops-team/issues/150\r\n\r\nThis PR
adds a new telemetry to the alerting plugin.\r\nThe task collects the
below data and saves in the task state.\r\n\r\n`count_alerts_total`
total alerts of all time\r\n`count_alerts_by_rule_type` total alerts of
all time by rule types\r\n\r\nNote: I tried to use the stats API as
Brandon suggested in the issue,\r\nbut it just returns the total number
of alerts.\r\nWe have to use aggregations for alerts by rule types.
Therefore I didn't\r\nuse it.\r\n\r\n## To verify:\r\n\r\n\r\n- Change
the task interval to 1m on
[this\r\nline](https://github.com/elastic/kibana/pull/192866/files#diff-014c1a7c63ade0d0f548523ef161369fdeb21c589a8112f202b8086ca23af6fdL32)\r\n-
Run Kibana\r\n- Create some rules that generates alerts.\r\n- Let them
run for a while.\r\n- Check the saved alerting telemetry in the task
state by using the\r\nbelow query.\r\n- `count_alerts_total`and
`count_alerts_by_rule_type` should be\r\npopulated\r\n\r\n```\r\nGET
/.kibana_task_manager_*/_search\r\n{\r\n \"query\": {\r\n \"term\":
{\r\n \"task.taskType\": \"alerting_telemetry\" \r\n }\r\n },\r\n
\"size\" :
1\r\n}\r\n```","sha":"5832d44767f98a625603ed27b80d2d33bb29132a"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/192866","number":192866,"mergeCommit":{"message":"Total
number of alerts, broken down by alerting rule types telemetry
(#192866)\n\nResolves:
https://github.com/elastic/response-ops-team/issues/150\r\n\r\nThis PR
adds a new telemetry to the alerting plugin.\r\nThe task collects the
below data and saves in the task state.\r\n\r\n`count_alerts_total`
total alerts of all time\r\n`count_alerts_by_rule_type` total alerts of
all time by rule types\r\n\r\nNote: I tried to use the stats API as
Brandon suggested in the issue,\r\nbut it just returns the total number
of alerts.\r\nWe have to use aggregations for alerts by rule types.
Therefore I didn't\r\nuse it.\r\n\r\n## To verify:\r\n\r\n\r\n- Change
the task interval to 1m on
[this\r\nline](https://github.com/elastic/kibana/pull/192866/files#diff-014c1a7c63ade0d0f548523ef161369fdeb21c589a8112f202b8086ca23af6fdL32)\r\n-
Run Kibana\r\n- Create some rules that generates alerts.\r\n- Let them
run for a while.\r\n- Check the saved alerting telemetry in the task
state by using the\r\nbelow query.\r\n- `count_alerts_total`and
`count_alerts_by_rule_type` should be\r\npopulated\r\n\r\n```\r\nGET
/.kibana_task_manager_*/_search\r\n{\r\n \"query\": {\r\n \"term\":
{\r\n \"task.taskType\": \"alerting_telemetry\" \r\n }\r\n },\r\n
\"size\" :
1\r\n}\r\n```","sha":"5832d44767f98a625603ed27b80d2d33bb29132a"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Ersin Erdal <92688503+ersin-erdal@users.noreply.github.com>
2024-09-25 15:21:44 -05:00
Kibana Machine
86a065d77c
[8.x] [ReaponseOps] Add name property to audit logs SO (#193323) (#193954)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[ReaponseOps] Add name property to audit logs SO
(#193323)](https://github.com/elastic/kibana/pull/193323)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT
[{"author":{"name":"Julia","email":"iuliia.guskova@elastic.co"},"sourceCommit":{"committedDate":"2024-09-25T09:34:55Z","message":"[ReaponseOps]
Add name property to audit logs SO (#193323)\n\nIssue:
https://github.com/elastic/enhancements/issues/19823\r\n\r\nSo the
purpose of this PR is to add a rule name to each audit log
in\r\nalerting API.\r\nPreviously if with a rule was done some action
(like create, delete,\r\netc.), the user could see it in an audit log.
But this log included only\r\nrule SO id, but not name. Users wanted to
see a rule name associated\r\nwith the audit log.\r\nSo here I added
it.\r\n\r\nThe principle I follow here to accelerate development (agreed
with\r\n@cnasikas): if it is easy (name easy to extract in the code
the\r\n`savedObject`) to pass it. If it is not do not.\r\n\r\n###
Checklist\r\n\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios","sha":"45b4089371f5b7694fde7d08b6a7aaeb70c4a56e","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[ReaponseOps]
Add name property to audit logs
SO","number":193323,"url":"https://github.com/elastic/kibana/pull/193323","mergeCommit":{"message":"[ReaponseOps]
Add name property to audit logs SO (#193323)\n\nIssue:
https://github.com/elastic/enhancements/issues/19823\r\n\r\nSo the
purpose of this PR is to add a rule name to each audit log
in\r\nalerting API.\r\nPreviously if with a rule was done some action
(like create, delete,\r\netc.), the user could see it in an audit log.
But this log included only\r\nrule SO id, but not name. Users wanted to
see a rule name associated\r\nwith the audit log.\r\nSo here I added
it.\r\n\r\nThe principle I follow here to accelerate development (agreed
with\r\n@cnasikas): if it is easy (name easy to extract in the code
the\r\n`savedObject`) to pass it. If it is not do not.\r\n\r\n###
Checklist\r\n\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios","sha":"45b4089371f5b7694fde7d08b6a7aaeb70c4a56e"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/193323","number":193323,"mergeCommit":{"message":"[ReaponseOps]
Add name property to audit logs SO (#193323)\n\nIssue:
https://github.com/elastic/enhancements/issues/19823\r\n\r\nSo the
purpose of this PR is to add a rule name to each audit log
in\r\nalerting API.\r\nPreviously if with a rule was done some action
(like create, delete,\r\netc.), the user could see it in an audit log.
But this log included only\r\nrule SO id, but not name. Users wanted to
see a rule name associated\r\nwith the audit log.\r\nSo here I added
it.\r\n\r\nThe principle I follow here to accelerate development (agreed
with\r\n@cnasikas): if it is easy (name easy to extract in the code
the\r\n`savedObject`) to pass it. If it is not do not.\r\n\r\n###
Checklist\r\n\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios","sha":"45b4089371f5b7694fde7d08b6a7aaeb70c4a56e"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Julia <iuliia.guskova@elastic.co>
2024-09-25 06:06:47 -05:00
Kibana Machine
9c356e8804
[8.x] [Response Ops][Rules] Rule Model Version Forward Compat (#193233) (#193695)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Rules] Rule Model Version Forward Compat
(#193233)](https://github.com/elastic/kibana/pull/193233)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Jiawei
Wu","email":"74562234+JiaweiWu@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-09-20T08:50:54Z","message":"[Response
Ops][Rules] Rule Model Version Forward Compat (#193233)\n\n##
Summary\r\n\r\nThis PR implements the `forwardCompatibility` field for
the rule model\r\nversion in preparation for the flapping
PR\r\n(https://github.com/elastic/kibana/pull/190019). We're doing this
so we\r\nhave the point to revert back to if we need to where
the\r\n`forwardCompatibility` is
defined.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"bb1899653f6fc077d443a600bce6c6f2fc775964","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[Response
Ops][Rules] Rule Model Version Forward
Compat","number":193233,"url":"https://github.com/elastic/kibana/pull/193233","mergeCommit":{"message":"[Response
Ops][Rules] Rule Model Version Forward Compat (#193233)\n\n##
Summary\r\n\r\nThis PR implements the `forwardCompatibility` field for
the rule model\r\nversion in preparation for the flapping
PR\r\n(https://github.com/elastic/kibana/pull/190019). We're doing this
so we\r\nhave the point to revert back to if we need to where
the\r\n`forwardCompatibility` is
defined.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"bb1899653f6fc077d443a600bce6c6f2fc775964"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/193233","number":193233,"mergeCommit":{"message":"[Response
Ops][Rules] Rule Model Version Forward Compat (#193233)\n\n##
Summary\r\n\r\nThis PR implements the `forwardCompatibility` field for
the rule model\r\nversion in preparation for the flapping
PR\r\n(https://github.com/elastic/kibana/pull/190019). We're doing this
so we\r\nhave the point to revert back to if we need to where
the\r\n`forwardCompatibility` is
defined.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"bb1899653f6fc077d443a600bce6c6f2fc775964"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Jiawei Wu <74562234+JiaweiWu@users.noreply.github.com>
2024-09-23 07:09:14 -05:00
Kibana Machine
e2edfd5017
[8.x] [ResponseOps][Rules] Add OAS schema for handled 4xx errors on rule apis (#192616) (#193454)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[ResponseOps][Rules] Add OAS schema for handled 4xx errors on rule
apis (#192616)](https://github.com/elastic/kibana/pull/192616)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Zacqary Adam
Xeper","email":"Zacqary@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-09-19T16:52:17Z","message":"[ResponseOps][Rules]
Add OAS schema for handled 4xx errors on rule apis (#192616)\n\n##
Summary\r\n\r\nCloses #188514 \r\n\r\nAdds OAS schemas for the `403
Forbidden` errors that public rule apis\r\ncan return if a license is
invalid, `400 Bad Request` for unregistered\r\nrule types, and `404 Not
Found` for missing saved objects.\r\n\r\n### Checklist\r\n\r\n- [x] Any
text added follows [EUI's
writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing),
uses\r\nsentence case text and includes
[i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n-
[x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n\r\n###
Testing\r\n\r\n1. Start ES\r\n2. Add `server.oas.enabled: true` to
`kibana.dev.yml`\r\n3. Start Kibana `yarn start --no-base-path`\r\n4.
`curl -s
-uelastic:changeme\r\nhttp://localhost:5601/api/oas\\?pathStartsWith\\=/api/alerting/rule/
| jq`\r\n(If you have `jq` installed, otherwise pipe to `pbcopy` and
paste the\r\nresult into a JSON prettifier)\r\n5. Search the output for
the word `Forbidden` to ensure this schema has\r\nbeen added to
`create`, `update`, `enable`, `disable`, `mute`, `unmute`,\r\nand
`update_rule_api_key`\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"18afcae609c9dd142ef158f6f19dd392bc9d6327","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","Feature:Alerting/RulesFramework","v8.16.0","backport:version"],"title":"[ResponseOps][Rules]
Add OAS schema for handled 4xx errors on rule
apis","number":192616,"url":"https://github.com/elastic/kibana/pull/192616","mergeCommit":{"message":"[ResponseOps][Rules]
Add OAS schema for handled 4xx errors on rule apis (#192616)\n\n##
Summary\r\n\r\nCloses #188514 \r\n\r\nAdds OAS schemas for the `403
Forbidden` errors that public rule apis\r\ncan return if a license is
invalid, `400 Bad Request` for unregistered\r\nrule types, and `404 Not
Found` for missing saved objects.\r\n\r\n### Checklist\r\n\r\n- [x] Any
text added follows [EUI's
writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing),
uses\r\nsentence case text and includes
[i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n-
[x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n\r\n###
Testing\r\n\r\n1. Start ES\r\n2. Add `server.oas.enabled: true` to
`kibana.dev.yml`\r\n3. Start Kibana `yarn start --no-base-path`\r\n4.
`curl -s
-uelastic:changeme\r\nhttp://localhost:5601/api/oas\\?pathStartsWith\\=/api/alerting/rule/
| jq`\r\n(If you have `jq` installed, otherwise pipe to `pbcopy` and
paste the\r\nresult into a JSON prettifier)\r\n5. Search the output for
the word `Forbidden` to ensure this schema has\r\nbeen added to
`create`, `update`, `enable`, `disable`, `mute`, `unmute`,\r\nand
`update_rule_api_key`\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"18afcae609c9dd142ef158f6f19dd392bc9d6327"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/192616","number":192616,"mergeCommit":{"message":"[ResponseOps][Rules]
Add OAS schema for handled 4xx errors on rule apis (#192616)\n\n##
Summary\r\n\r\nCloses #188514 \r\n\r\nAdds OAS schemas for the `403
Forbidden` errors that public rule apis\r\ncan return if a license is
invalid, `400 Bad Request` for unregistered\r\nrule types, and `404 Not
Found` for missing saved objects.\r\n\r\n### Checklist\r\n\r\n- [x] Any
text added follows [EUI's
writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing),
uses\r\nsentence case text and includes
[i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n-
[x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n\r\n###
Testing\r\n\r\n1. Start ES\r\n2. Add `server.oas.enabled: true` to
`kibana.dev.yml`\r\n3. Start Kibana `yarn start --no-base-path`\r\n4.
`curl -s
-uelastic:changeme\r\nhttp://localhost:5601/api/oas\\?pathStartsWith\\=/api/alerting/rule/
| jq`\r\n(If you have `jq` installed, otherwise pipe to `pbcopy` and
paste the\r\nresult into a JSON prettifier)\r\n5. Search the output for
the word `Forbidden` to ensure this schema has\r\nbeen added to
`create`, `update`, `enable`, `disable`, `mute`, `unmute`,\r\nand
`update_rule_api_key`\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"18afcae609c9dd142ef158f6f19dd392bc9d6327"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Zacqary Adam Xeper <Zacqary@users.noreply.github.com>
2024-09-19 13:32:07 -05:00
Elena Shostak
518533898a
[8.x] Added scope field to features config. (#191634) (#193389)
# Backport

This will backport the following commits from `main` to `8.x`:
- [Added scope field to features config.
(#191634)](https://github.com/elastic/kibana/pull/191634)

<!--- Backport version: 8.9.8 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Elena
Shostak","email":"165678770+elena-shostak@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-09-13T00:22:20Z","message":"Added
scope field to features config. (#191634)\n\n## Summary\r\nKibana needs
to more tightly control the set of visible features within\r\na space,
in order to support the new solution-based navigation.\r\nAdded `scope`
field to the features configuration. This enhancement is\r\nintended to
prevent new features from appearing in Space
Visibility\r\nToggles.\r\n\r\n\r\n### Checklist\r\n\r\n-
[x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n- [x] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n\r\n__Fixes:
https://github.com/elastic/kibana/issues/191299__\r\n\r\n## Release
Note\r\n\r\nAdded `scope` field to the features configuration. This
enhancement is\r\nintended to prevent new features from appearing in
Space Visibility\r\nToggles.\r\n\r\n---------\r\n\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"a71c9ba38ab4b88288313b91bd1b699777b3aab1","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:enhancement","chore","Team:Security","Feature:Security/Spaces","backport:skip","Team:Fleet","v9.0.0","Team:Obs
AI
Assistant","ci:project-deploy-observability","Team:obs-ux-infra_services","Team:obs-ux-management","apm:review"],"number":191634,"url":"https://github.com/elastic/kibana/pull/191634","mergeCommit":{"message":"Added
scope field to features config. (#191634)\n\n## Summary\r\nKibana needs
to more tightly control the set of visible features within\r\na space,
in order to support the new solution-based navigation.\r\nAdded `scope`
field to the features configuration. This enhancement is\r\nintended to
prevent new features from appearing in Space
Visibility\r\nToggles.\r\n\r\n\r\n### Checklist\r\n\r\n-
[x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n- [x] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n\r\n__Fixes:
https://github.com/elastic/kibana/issues/191299__\r\n\r\n## Release
Note\r\n\r\nAdded `scope` field to the features configuration. This
enhancement is\r\nintended to prevent new features from appearing in
Space Visibility\r\nToggles.\r\n\r\n---------\r\n\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"a71c9ba38ab4b88288313b91bd1b699777b3aab1"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/191634","number":191634,"mergeCommit":{"message":"Added
scope field to features config. (#191634)\n\n## Summary\r\nKibana needs
to more tightly control the set of visible features within\r\na space,
in order to support the new solution-based navigation.\r\nAdded `scope`
field to the features configuration. This enhancement is\r\nintended to
prevent new features from appearing in Space
Visibility\r\nToggles.\r\n\r\n\r\n### Checklist\r\n\r\n-
[x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n- [x] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n\r\n__Fixes:
https://github.com/elastic/kibana/issues/191299__\r\n\r\n## Release
Note\r\n\r\nAdded `scope` field to the features configuration. This
enhancement is\r\nintended to prevent new features from appearing in
Space Visibility\r\nToggles.\r\n\r\n---------\r\n\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"a71c9ba38ab4b88288313b91bd1b699777b3aab1"}}]}]
BACKPORT-->

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
2024-09-19 10:42:43 -05:00
Kibana Machine
676d73fbe5
[8.x] [ResponseOps][MW] Add telemetry for the maintenance window (#192483) (#193395)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[ResponseOps][MW] Add telemetry for the maintenance window
(#192483)](https://github.com/elastic/kibana/pull/192483)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT
[{"author":{"name":"Julia","email":"iuliia.guskova@elastic.co"},"sourceCommit":{"committedDate":"2024-09-19T08:28:48Z","message":"[ResponseOps][MW]
Add telemetry for the maintenance window (#192483)\n\nResolve:
https://github.com/elastic/kibana/issues/184088\r\n\r\nIn this PR add
telemetry collection of these metrics:\r\n\r\n- total number of MW in
deployments\r\n- number of active MW with \"repeat\" toggle on (time
based)\r\n- number of active MW with \"filter alerts\" toggle on (KQL
based)\r\n\r\n## Testing\r\n\r\nCreate several MW with different
settings (toggles on and off)\r\nTo test changes reflected in telemetry
object, \r\nmodify this file:
`x-pack/plugins/alerting/server/usage/task.ts`\r\n\r\nWith:\r\n\r\n```\r\nasync
function scheduleTasks(logger: Logger, taskManager:
TaskManagerStartContract) {\r\n try {\r\n await
taskManager.ensureScheduled({\r\n id: TASK_ID,\r\n taskType:
TELEMETRY_TASK_TYPE,\r\n state: emptyState,\r\n params: {},\r\n
schedule: SCHEDULE,\r\n });\r\n } catch (e) {\r\n logger.error(`Error
scheduling ${TASK_ID}, received ${e.message}`);\r\n }\r\n await
taskManager.runSoon(TASK_ID);\r\n}\r\n```\r\n\r\nThis will cause the
telemetry to be sent as soon as the server is\r\nrestarted.\r\n\r\n**Run
Telemetry usage payload API in your browser console to
verify\r\ntelemetry
object:**\r\n\r\nhttps://docs.elastic.dev/telemetry/collection/snapshot-telemetry#telemetry-usage-payload-api\r\nP.S.:
Add space at the beginning of URL\r\n\r\n\r\n### Checklist\r\n\r\n- [x]
[Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"eabb1022815a7c661a0e642c62d0a77ce338f9c9","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Team:ResponseOps","v9.0.0","v8.16.0"],"title":"[ResponseOps][MW]
Add telemetry for the maintenance
window","number":192483,"url":"https://github.com/elastic/kibana/pull/192483","mergeCommit":{"message":"[ResponseOps][MW]
Add telemetry for the maintenance window (#192483)\n\nResolve:
https://github.com/elastic/kibana/issues/184088\r\n\r\nIn this PR add
telemetry collection of these metrics:\r\n\r\n- total number of MW in
deployments\r\n- number of active MW with \"repeat\" toggle on (time
based)\r\n- number of active MW with \"filter alerts\" toggle on (KQL
based)\r\n\r\n## Testing\r\n\r\nCreate several MW with different
settings (toggles on and off)\r\nTo test changes reflected in telemetry
object, \r\nmodify this file:
`x-pack/plugins/alerting/server/usage/task.ts`\r\n\r\nWith:\r\n\r\n```\r\nasync
function scheduleTasks(logger: Logger, taskManager:
TaskManagerStartContract) {\r\n try {\r\n await
taskManager.ensureScheduled({\r\n id: TASK_ID,\r\n taskType:
TELEMETRY_TASK_TYPE,\r\n state: emptyState,\r\n params: {},\r\n
schedule: SCHEDULE,\r\n });\r\n } catch (e) {\r\n logger.error(`Error
scheduling ${TASK_ID}, received ${e.message}`);\r\n }\r\n await
taskManager.runSoon(TASK_ID);\r\n}\r\n```\r\n\r\nThis will cause the
telemetry to be sent as soon as the server is\r\nrestarted.\r\n\r\n**Run
Telemetry usage payload API in your browser console to
verify\r\ntelemetry
object:**\r\n\r\nhttps://docs.elastic.dev/telemetry/collection/snapshot-telemetry#telemetry-usage-payload-api\r\nP.S.:
Add space at the beginning of URL\r\n\r\n\r\n### Checklist\r\n\r\n- [x]
[Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"eabb1022815a7c661a0e642c62d0a77ce338f9c9"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/192483","number":192483,"mergeCommit":{"message":"[ResponseOps][MW]
Add telemetry for the maintenance window (#192483)\n\nResolve:
https://github.com/elastic/kibana/issues/184088\r\n\r\nIn this PR add
telemetry collection of these metrics:\r\n\r\n- total number of MW in
deployments\r\n- number of active MW with \"repeat\" toggle on (time
based)\r\n- number of active MW with \"filter alerts\" toggle on (KQL
based)\r\n\r\n## Testing\r\n\r\nCreate several MW with different
settings (toggles on and off)\r\nTo test changes reflected in telemetry
object, \r\nmodify this file:
`x-pack/plugins/alerting/server/usage/task.ts`\r\n\r\nWith:\r\n\r\n```\r\nasync
function scheduleTasks(logger: Logger, taskManager:
TaskManagerStartContract) {\r\n try {\r\n await
taskManager.ensureScheduled({\r\n id: TASK_ID,\r\n taskType:
TELEMETRY_TASK_TYPE,\r\n state: emptyState,\r\n params: {},\r\n
schedule: SCHEDULE,\r\n });\r\n } catch (e) {\r\n logger.error(`Error
scheduling ${TASK_ID}, received ${e.message}`);\r\n }\r\n await
taskManager.runSoon(TASK_ID);\r\n}\r\n```\r\n\r\nThis will cause the
telemetry to be sent as soon as the server is\r\nrestarted.\r\n\r\n**Run
Telemetry usage payload API in your browser console to
verify\r\ntelemetry
object:**\r\n\r\nhttps://docs.elastic.dev/telemetry/collection/snapshot-telemetry#telemetry-usage-payload-api\r\nP.S.:
Add space at the beginning of URL\r\n\r\n\r\n### Checklist\r\n\r\n- [x]
[Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"eabb1022815a7c661a0e642c62d0a77ce338f9c9"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Julia <iuliia.guskova@elastic.co>
2024-09-19 04:57:32 -05:00
Kibana Machine
9eb32483b8
[8.x] [EDR Workflows] Automated Actions in more rule types (#191874) (#193338)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[EDR Workflows] Automated Actions in more rule types
(#191874)](https://github.com/elastic/kibana/pull/191874)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Tomasz
Ciecierski","email":"tomasz.ciecierski@elastic.co"},"sourceCommit":{"committedDate":"2024-09-18T16:56:06Z","message":"[EDR
Workflows] Automated Actions in more rule types
(#191874)","sha":"004631b6c229d9d87e43c1dc73321c90efb857dc","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","Team:Defend
Workflows","v8.16.0"],"title":"[EDR Workflows] Automated Actions in more
rule
types","number":191874,"url":"https://github.com/elastic/kibana/pull/191874","mergeCommit":{"message":"[EDR
Workflows] Automated Actions in more rule types
(#191874)","sha":"004631b6c229d9d87e43c1dc73321c90efb857dc"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/191874","number":191874,"mergeCommit":{"message":"[EDR
Workflows] Automated Actions in more rule types
(#191874)","sha":"004631b6c229d9d87e43c1dc73321c90efb857dc"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Tomasz Ciecierski <tomasz.ciecierski@elastic.co>
2024-09-18 14:10:04 -05:00
Kibana Machine
7939f22c42
[8.x] [Response Ops][Alerting] Creating global service for fetching and caching rules settings (#192404) (#193011)
# Backport

This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Alerting] Creating global service for fetching and
caching rules settings
(#192404)](https://github.com/elastic/kibana/pull/192404)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Ying
Mao","email":"ying.mao@elastic.co"},"sourceCommit":{"committedDate":"2024-09-16T13:22:44Z","message":"[Response
Ops][Alerting] Creating global service for fetching and caching rules
settings (#192404)\n\nResolves
https://github.com/elastic/kibana/issues/184321
and\r\nhttps://github.com/elastic/kibana/issues/149884\r\n\r\n##
Summary\r\n\r\nCreated a `RulesSettingsService` that caches flapping and
query delay\r\nsettings per space for 1 minute so rules are not
accessing the SO index\r\nwith every execution.\r\n\r\nAlso moved all
classes related to the rules settings into the\r\n`rules_settings`
folder so some of these changes are just renaming\r\nchanges.\r\n\r\n##
To Verify\r\n1. Add some logging
to\r\n`x-pack/plugins/alerting/server/rules_settings/rules_settings_service.ts`\r\nto
indicate when settings are being fetched and when they're
returning\r\nfrom the cache.\r\n2. Create and run some rules in
different spaces to see that flapping\r\nand query delay settings are
being returned from the cache when the\r\ncache has not
expired.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"7a0fe2e83683cf38c537694daa88a3a75bfe3e57","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"title":"[Response
Ops][Alerting] Creating global service for fetching and caching rules
settings","number":192404,"url":"https://github.com/elastic/kibana/pull/192404","mergeCommit":{"message":"[Response
Ops][Alerting] Creating global service for fetching and caching rules
settings (#192404)\n\nResolves
https://github.com/elastic/kibana/issues/184321
and\r\nhttps://github.com/elastic/kibana/issues/149884\r\n\r\n##
Summary\r\n\r\nCreated a `RulesSettingsService` that caches flapping and
query delay\r\nsettings per space for 1 minute so rules are not
accessing the SO index\r\nwith every execution.\r\n\r\nAlso moved all
classes related to the rules settings into the\r\n`rules_settings`
folder so some of these changes are just renaming\r\nchanges.\r\n\r\n##
To Verify\r\n1. Add some logging
to\r\n`x-pack/plugins/alerting/server/rules_settings/rules_settings_service.ts`\r\nto
indicate when settings are being fetched and when they're
returning\r\nfrom the cache.\r\n2. Create and run some rules in
different spaces to see that flapping\r\nand query delay settings are
being returned from the cache when the\r\ncache has not
expired.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"7a0fe2e83683cf38c537694daa88a3a75bfe3e57"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/192404","number":192404,"mergeCommit":{"message":"[Response
Ops][Alerting] Creating global service for fetching and caching rules
settings (#192404)\n\nResolves
https://github.com/elastic/kibana/issues/184321
and\r\nhttps://github.com/elastic/kibana/issues/149884\r\n\r\n##
Summary\r\n\r\nCreated a `RulesSettingsService` that caches flapping and
query delay\r\nsettings per space for 1 minute so rules are not
accessing the SO index\r\nwith every execution.\r\n\r\nAlso moved all
classes related to the rules settings into the\r\n`rules_settings`
folder so some of these changes are just renaming\r\nchanges.\r\n\r\n##
To Verify\r\n1. Add some logging
to\r\n`x-pack/plugins/alerting/server/rules_settings/rules_settings_service.ts`\r\nto
indicate when settings are being fetched and when they're
returning\r\nfrom the cache.\r\n2. Create and run some rules in
different spaces to see that flapping\r\nand query delay settings are
being returned from the cache when the\r\ncache has not
expired.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"7a0fe2e83683cf38c537694daa88a3a75bfe3e57"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Ying Mao <ying.mao@elastic.co>
2024-09-16 10:30:31 -05:00
Maryam Saeidi
4d5c25305b
[Custom threshold] Improve the custom threshold rule request/response logging (#192443)
Related to #187271

## Summary

As mentioned in this
[PR](https://github.com/elastic/kibana/pull/187225), when logging a JSON
stringified string for debugging or tracing, we need to wrap it in a
function. This PR does this for the custom threshold rule and removes
extra request/response logging, relying on alerting framework logging
for that purpose.


![image](https://github.com/user-attachments/assets/c1fa8bb2-e895-4aae-a8da-b74fe5a8ca1e)

Before, we were able to have a similar log using `plugins.observability`
and `plugins.alerting.observability.rules.custom_threshold` configs (as
shown above), but now we only have
`plugins.alerting.observability.rules.custom_threshold` which can be
enabled by either of the following configs:

```
logging:
  loggers:
    - name: plugins.alerting
      level: debug
    - name: plugins.alerting.observability.rules.custom_threshold
      level: trace
```

Thanks @dgieselaar for bringing this to our attention!

### How to test
- Enable the trace logging config as mentioned above
- Create a custom threshold rule and check the server logs; you should
be able to see the logs for the request and response of the rule
execution.
2024-09-12 14:57:11 +02:00
Janki Salvi
ef6b657a30
[ResponseOps][Rules] Fix inconsistencies in bulk enable/disable rules (#191492)
Resolves https://github.com/elastic/kibana/issues/181050

## Summary
This PR 
- fixes `Inconsistent responses from RulesClient` by updating the
`bulkEnable` and `bulkDisable` rules apis to return all the rules that
were in the payload.
So below scenarios will return:
    - Both rules initially disabled:
      ```typescript
      { 
        "errors": [], 
        "rules": [{...}, {...}], // <- all rules are returned
        "total": 2 
      }
      ``` 
   - One rule disabled, one enabled:
      ```typescript
      { 
        "errors": [], 
        "rules": [{...}, {...}], // <- all rules are returned
        "total": 2 
      }
      ``` 
   - Both rules initially enabled:
      ```typescript
      { 
        "errors": [], 
        "rules": [{...}, {...}], // <- all rules are returned
        "total": 2 
      }
      ``` 

### How to verify
- Create two (detection engine SIEM / Observability / Stack) rules, one
enable and one disable
- Select both rules and bulk enable them via UI OR
- Enable 2 rules via API 
- Verify both rules are returned in response 

### 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
2024-09-10 09:21:02 +01:00
Jiawei Wu
0b980d8d9d
[ResponseOps][Maintenance Window] Remove MW scoped query feature flag (#172900)
## Summary
Removes the scoped query feature flag as it is no longer needed.

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
2024-09-09 16:31:14 -07:00
Ying Mao
a8d758b758
[Response Ops][Alerting] Removing second call to load rule at end of rule execution (#192402)
Resolves https://github.com/elastic/kibana/issues/192396

## Summary

Removes second call to load rule at the end of the rule execution. This
call was meant to get any changes to the rule schedule that users may
have initiated during rule execution but there is a lot of overhead in
loading a rule and any changes to the schedule would be captured during
the next execution anyway.

## To Verify

1. Add some logging and a delay to rule execution after the initial rule
load:

```
--- a/x-pack/plugins/alerting/server/task_runner/task_runner.ts
+++ b/x-pack/plugins/alerting/server/task_runner/task_runner.ts
@@ -684,6 +684,10 @@ export class TaskRunner<
       schedule = asErr(err);
     }

+    this.logger.info(`STARTING RULE EXECUTION`);
+
+    await new Promise((r) => setTimeout(r, 30000));
+
     await withAlertingSpan('alerting:process-run-results-and-update-rule', () =>
```

2. Start Kibana and create a rule with a schedule of 3 minutes.
3. Wait for the rule to run and log, then change the schedule interval
to something else.
4. The next execution of the rule should still occur 3 minutes later,
and then further executions should occur on the new schedule.
2024-09-09 16:09:34 -04:00
Khristinin Nikita
af399c1177
Add intended timestamp (#191717)
## Add new field to alert


Add optional `kibana.alert.intended_timestamp`. For scheduled rules it
has the same values as ALERT_RULE_EXECUTION_TIMESTAMP
(`kibana.alert.rule.execution.timestamp`)

for manual rule runs (backfill) it - will get the startedAtOverridden 

For example if i have event at 14:30

And if we run manual rule run from 14:00-15:00, then alert will have
`kibana.alert.intended_timestamp` at 15:00

---------

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
2024-09-09 21:45:08 +02:00