mirror of
https://github.com/elastic/kibana.git
synced 2025-04-22 08:49:27 -04:00
861 commits
Author | SHA1 | Message | Date | |
---|---|---|---|---|
|
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> |
||
|
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--> |
||
|
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> |
||
|
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--> |
||
|
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> |
||
|
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--> |
||
|
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\n |
||
|
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--> |
||
|
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> |
||
|
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) (
|
||
|
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> |
||
|
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\r\n\r\n2. Create a maintenance window with the following scoped query: \r\n\r\n\r\n\r\n3. Create a ES query rule and trigger actions:\r\n\r\n\r\n\r\n4. Assert the `maintenance_window_id` on the 4 alerts are set\r\n\r\n\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\r\n\r\n2. Create a maintenance window with the following scoped query: \r\n\r\n\r\n\r\n3. Create a ES query rule and trigger actions:\r\n\r\n\r\n\r\n4. Assert the `maintenance_window_id` on the 4 alerts are set\r\n\r\n\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\r\n\r\n2. Create a maintenance window with the following scoped query: \r\n\r\n\r\n\r\n3. Create a ES query rule and trigger actions:\r\n\r\n\r\n\r\n4. Assert the `maintenance_window_id` on the 4 alerts are set\r\n\r\n\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> |
||
|
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> |
||
|
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> |
||
|
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--> |
||
|
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]( |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
b44b90d3a8
|
[8.x] [Response Ops][Alerting] Refactor `ExecutionHandler` stage 2 (#193807) (#195676)
# Backport This will backport the following commits from `main` to `8.x`: - [[Response Ops][Alerting] Refactor `ExecutionHandler` 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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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=\" |
||
|
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> |
||
|
464430dd87
|
[8.x] [ResponseOps][Alerts] Fix authorization issues with `discover` as consumers (#192321) (#194441)
# Backport This will backport the following commits from `main` to `8.x`: - [[ResponseOps][Alerts] Fix authorization issues with `discover` 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> |
||
|
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> |
||
|
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--> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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.  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. |
||
|
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 |
||
|
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> |
||
|
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. |
||
|
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> |