# Backport
This will backport the following commits from `main` to `8.11`:
- [[RAM] Improve rule interval circuit breaker error message
(#168173)](https://github.com/elastic/kibana/pull/168173)
<!--- Backport version: 8.9.7 -->
### 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":"2023-10-13T17:22:25Z","message":"[RAM]
Improve rule interval circuit breaker error message (#168173)\n\n##
Summary\r\nImprove rule interval circuit breaker error message to the
following\r\nendpoints:\r\n\r\n- create\r\n- update\r\n- bulk edit\r\n-
bulk enable\r\n\r\n### Bulk modification\r\n\r\n\r\n###
Modifying a single rule\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: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Xavier Mouligneau
<xavier.mouligneau@elastic.co>","sha":"c66a86b07ebf267aaeed5304bd091ba87443fae2","branchLabelMapping":{"^v8.12.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["enhancement","release_note:skip","Team:ResponseOps","Feature:Alerting/RulesManagement","ui-copy","v8.11.0","v8.12.0"],"number":168173,"url":"https://github.com/elastic/kibana/pull/168173","mergeCommit":{"message":"[RAM]
Improve rule interval circuit breaker error message (#168173)\n\n##
Summary\r\nImprove rule interval circuit breaker error message to the
following\r\nendpoints:\r\n\r\n- create\r\n- update\r\n- bulk edit\r\n-
bulk enable\r\n\r\n### Bulk modification\r\n\r\n\r\n###
Modifying a single rule\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: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Xavier Mouligneau
<xavier.mouligneau@elastic.co>","sha":"c66a86b07ebf267aaeed5304bd091ba87443fae2"}},"sourceBranch":"main","suggestedTargetBranches":["8.11"],"targetPullRequestStates":[{"branch":"8.11","label":"v8.11.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.12.0","labelRegex":"^v8.12.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/168173","number":168173,"mergeCommit":{"message":"[RAM]
Improve rule interval circuit breaker error message (#168173)\n\n##
Summary\r\nImprove rule interval circuit breaker error message to the
following\r\nendpoints:\r\n\r\n- create\r\n- update\r\n- bulk edit\r\n-
bulk enable\r\n\r\n### Bulk modification\r\n\r\n\r\n###
Modifying a single rule\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: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Xavier Mouligneau
<xavier.mouligneau@elastic.co>","sha":"c66a86b07ebf267aaeed5304bd091ba87443fae2"}}]}]
BACKPORT-->
Co-authored-by: Jiawei Wu <74562234+JiaweiWu@users.noreply.github.com>
# Backport
This will backport the following commits from `main` to `8.11`:
- [[8.11] [RAM] Bring back toggle column on alert table
(#168158)](https://github.com/elastic/kibana/pull/168158)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
---------
Co-authored-by: PhilippeOberti <philippe.oberti@elastic.co>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
## Summary
Resolves: https://github.com/elastic/kibana/issues/166301
Adds support for solution/category filtering to maintenance windows by
adding a new property: `category_ids`. Selecting one or more solutions
when creating/updating a maintenance window will cause the maintenance
window to only suppress rule types belonging to said solutions. In order
to achieve filtering by solution/category, we are adding a new field to
the rule types schema called `category`. This field should map to the
feature category that the rule type belongs to (`observability`,
`securitySolution` or `management`).
Our initial plan was to use feature IDs or rule type IDs to accomplish
this filtering, we decided against using rule type IDs because if a new
rule type gets added, we need to change the API to support this new rule
type. We decided against feature IDs because it's a very anti-serverless
way of accomplishing this feature, as we don't want to expose feature
IDs to APIs. We decided on app categories because it works well with
serverless and should be much easier to maintain if new rule types are
added in the future.
This means the `rule_types` API has to be changed to include this new
field, although it shouldn't be a breaking change since we're just
adding a new field. No migrations are needed since rule types are in
memory and maintenance windows are backwards compatible.
### Error state:
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dima Arnautov <arnautov.dima@gmail.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/161788
Makes the global event log shareable. Plus some refactors like
converting the `rule_event_log_list_table` fetch to use React Query.
Also, fixed a bug with the `rule_status_panel` where we did not refresh
if the parent component refreshed.
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Follow up to #161676.
Since we added support for handling SSE-streams returned by OpenAI APIs
to `@kbn/ml-response-stream` in #162335, this updates the "Gen AI
Streaming Response" developer example to make use of the custom hook
`useFetchStream()` from `@kbn/ml-response-stream` instead of its inline
code to process the stream on the client.
It also improves the refresh behaviour: Previously, once a prompt was
entered and the accordion opened, every keystroke in the prompt textarea
would cause a new request to the AI endpoint. This update adds a
`Refresh prompt` to only do a new request on this user action. Support
for cancelling requests when unmounting the `StreamingResponse`
component was also added.
### Checklist
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/159598
## Summary
This PR modifies the `test` subaction of the Generative AI connector to
accept a `stream` parameter (default: `false`) that allows for a
streaming response.
The Generative AI connector is basically a pass-through to the Open
AI/Azure OpenAI APIs, where the `stream` parameter is passed in via the
body of the request. This means that with the existing connector, users
could specify `stream: true` in the body which would lead to unexpected
results when the action is unprepared to return streaming results. This
PR sanitizes the body that is passed in the `run` subaction to prevent
the `stream` parameter from being set to `true` and explicitly sets the
`stream` parameter for the `test` subaction.
In order to test the streaming response, I created an example plugin
that prompts users to create a Generative AI connector if one does not
exist and then executes actions using the connector with `stream` set to
`true`. This borrows liberally from @dgieselaar's existing work from
https://github.com/elastic/kibana/pull/158678441694cb-0154-4450-bd93-3907c4a9995c
## To Verify
1. Navigate to https://localhost:5601/app/GenAiStreamingResponseExample
2. Set up a Generative AI connector
3. Open the network console. Enter a prompt and click `Stream Response`
4. You should see the chat response return streaming results.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/157203
Closes https://github.com/elastic/kibana/issues/158051
Closes https://github.com/elastic/kibana/issues/158049
With the addition of Per User Dark Mode, components can no longer rely
on `uiSettings` as the source of truth for theme.
CodeEditor fields used to call `uiSettings` to determine if Dark Mode
was enabled, which had been provided in each callers Kibana React
Context.
The new source of truth for theme is the `CoreStart >
ThemeServiceStart`.
Currently, not all callers of CodeEditor provide the `theme` service in
their Kibana Context in a similar way and some callers don't provide it
at all.
This PR updates CodeEditor to get theme values from the Kibana Context
using a new `useKibanaTheme` react hook.
It also attempts audit the callers of CodeEditor to see if their Kibana
Context contains the theme service at the top level (Where I could add
theme to a caller's Context without major changes, I did. Some cases
will require CodeOwner guidance).
The new `useKibanaTheme` react hook will throw a TypeError if theme
isn't found in the top level of the Kibana Context, this will help with
testing as the component will not render. I will remove this after
testing so as not to introduce breaking changes.
## Testing
Please review files for which you are CODEOWNER.
I've attempted to tag all usages of `CodeEditor`/`CodeEditorFIeld` with
a TODO comment with one of the following scenarios:
1) a note where theme was provided already/where I made changes to
provide it in the appropriate context
2) I've asked for CODEOWNER guidance
For scenario 1, please pull and test that CodeEditor locally:
1. Enable Dark Mode from Edit User Profiles by clicking on the Profile
Icon on the top right, and updating your profile.
2. Navigate to the CodeEditors in the plugins you own. If they render
and display in Dark Mode - add a green check to the table below - and
you're done!
3. If it is not rendering, please help me figure out where the theme
service should be provided in the context.
For scenario 2, we will need to figure out where to make changes so your
context is providing theme. Some of the more complex usages may need to
addressed in separate issues.
## Tracking
| Team | Plugin | Theme in Context ? | Verified Working |
| - | - | - | - |
| apm-ui | apm | APM Storybook broken | ? |
| kibana-presentation | presentation_util | Yes. | Yes |
| response-ops | trigger_actions_ui | Yes | Yes |
| response-ops | stack_alerts | Yes | Yes |
| kibana-security | security | Yes | Yes |
| security-defend-workflows | osquery | Yes | Yes |
| kibana-app-services | examples/expression_explorer | Yes | Yes |
| ml-ui | transform | Yes | Yes |
| ml-ui | ml | Yes | Yes |
| uptime | synthetics | Yes | Yes |
| kibana-gis | maps | Yes | Yes |
| kibana-gis | file_upload | Yes | Yes |
| platform-deployment-management | watcher | Yes | [AG] Yes |
| platform-deployment-management | snapshot_restore | Yes | [AG] Yes |
| platform-deployment-management | runtime_fields | Yes | [AG] Yes |
| platform-deployment-management | painless_lab | Yes | [AG] Yes |
| platform-deployment-management | ingest_pipelines | Yes | [AG] Yes |
| platform-deployment-management | index_management | Yes | [AG] Yes |
| platform-deployment-management | grokdebugger | Yes | [AG] Yes |
| platform-deployment-management | es_ui_shared | Yes | [AG] Yes |
| fleet | fleet | Yes | Yes |
| enterprise-search-frontend | enterprise_search | Yes | [AG] Yes |
| kibana-cloud-security-posture | cloud-security-posture | Yes | yes |
| sec-cloudnative-integrations | cloud_defend | Yes | Yes |
| kibana-visualizations/kibana-data-discovery | data | Yes | Yes |
| kibana-visualizations | examples/testing_embedded_lens | Yes | Yes |
| kibana-visualizations | vis_types | Yes | Yes |
| kibana-visualizations | vis_default_editor | Yes | Yes |
| kibana-visualizations | unified_search | Yes | Yes |
| kibana-visualizations | packages/kbn-text-based-editor | Yes | Yes |
| kibana-visualizatons | lens | Yes | Yes|
| kibana-core | saved_objects_management | Yes | Yes |
| kibana-presentation | inspector | Yes | Yes |
| kibana-presentation | canvas | Yes | Yes |
| kibana-data-discovery | discover | Yes | Yes |
| kibana-data-discovery | data_view_management | Yes | Yes |
| kibana-data-discovery | data_view_field_editor | Yes | Yes |
| appex-sharedux | advanced_settings | Yes | Yes |
| enterprise-search-frontend | serverless_search | Yes | [AG] Yes |
| - | - | - | - |
## Unit tests
Currently, many tests are failing since they are probably not providing
`theme` in the context. Once CODEOWNERs have weighed in on CodeEditors
usages that require discussion, I will update the accompanying tests.
## Release note
- Fixes theming of CodeEditors
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Alison Goryachev <alisonmllr20@gmail.com>
Co-authored-by: Dima Arnautov <dmitrii.arnautov@elastic.co>
Co-authored-by: Dima Arnautov <arnautov.dima@gmail.com>
## Summary
The NativeRenderer component is currently used to mount another
component in a separate mounting point. As far as I recall, we
introduced <NativeRenderer/> to allow users to create visualizations in
non-React frameworks. The idea was that users could write their own Lens
visualizations or datasources code and integrate it with our system.
However, it seems that this concept hasn't gained traction and we don’t
have it prioritized. Even if users express interest in writing their
visualizations outside of React, it is still possible to do so with some
additional boilerplate code (which we could provide as an example
non-React visualization).
Pros:
1. Simplifies and shortens the code:
1.1. Testing and debugging become easier as we no longer need to check
separate React trees when integrating frame, data source, and
visualization components.
1.2. Components communicate using standard React patterns, making
maintenance and comprehension simpler.
1.3. Context providers no longer need to be passed to each separate
component since they are already within the context.
1.4. Easier propagation of events or any other form of inter-component
communication.
2. Greatly improves performance and facilitates maintenance:
2.1. Directly accessing context inside the DatasourcePanel eliminates
the need for context passing, resulting in better performance.
2.2. Removing the requirement for a separate React root also contributes
to improved performance.
3. The render method will be removed when we upgrade to React 18. While
we could replace it with the new createRoot method, it makes sense to
perform some cleanup ;)
Cons:
1. Setting up non-React visualization or data source code might become
slightly more complex.
Performance improvement for drag and drop action with these changes:
before:
<img width="1110" alt="Screenshot 2023-07-10 at 07 14 39"
src="45a1b09b-5189-46f5-af2b-7781fcf4e774">
after:
<img width="1117" alt="Screenshot 2023-07-10 at 07 16 24"
src="0e704da1-3220-4eb9-8fa0-cc3584a90090">
## Single render when dragging:
(the first image is 3 screenshots from 3 different react roots as they
have separate mounting point. The complete render time is ~380ms)
<img width="1117" alt="Screenshot 2023-07-10 at 07 16 24"
src="6d7f2d9f-a758-476e-8efb-38693ae90097">
After we have one common render tree. Because we don't have to pass
context down as a prop, we greatly reduced the number of components
rerendered. (I will be working on reducing the render time for workspace
panel as this seems to still be a bottleneck point)
<img width="732" alt="Screenshot 2023-07-10 at 14 52 41"
src="03ec97b3-8225-490e-8884-0fd4e69587e8">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes#160737
This PR adds support for title and description within the Embeddable
overrides realm.
While there also enables the support for overrides for the new TagCloud
visualization.
The playground example has been extended to test it for any type of
chart:
<img width="572" alt="Screenshot 2023-06-30 at 10 17 04"
src="8b069c2f-dd31-4aaa-9ded-0e33f34b4860">
### Checklist
Delete any items that are not applicable to this PR.
- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [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
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
`IVectorSource` interface has many similar sounding methods that are
used for different purposes. These lead to confusion and an unclear API
* getFieldNames
* getFields
* getFieldByName
Although `getFieldNames` sounds similar to `getFields`, the 2 are used
for very different purposes.
* getFieldNames returns a string array that is used to trigger source
re-fetch
* getFields returns an array of fields to drive UI such as field
selection for data driven styling
`getFieldNames` overlaps 100% in functionality with `getSyncMeta` and is
not needed. Combining output of `getFieldNames` into `getSyncMeta`
simplifies the `IVectorSource` API and removes some confusion.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Why?
To simplify the process of migration to react-router@6.
https://github.com/remix-run/react-router/discussions/8753
What problems exactly it solves?
- In my previous PR I added `CompatRouter`
https://github.com/elastic/kibana/pull/159173, which caused changes in
~50 files and pinged 15 Teams. And this is just meant to be a temporary
change, so when we're done with the migration I would have to revert
these changes and engage everyone to review the PR again. And it is just
a single step in the migration strategy. So to make our lives easier I
think it would be better to have a common place where we do import our
router components because it will allow us to surface some extra logic
in single place instead of going through the whole source code again.
- `react-router@6` doesn't support a custom `Route` component, so that
means our custom `Route` component that we're using almost everywhere
today, will need to be replaced by a different solution. I have decided
to add `Routes` component, which will be responsible for rendering the
proper component (`react-router@6` renamed `Switch` to `Routes`, so I
have named this component to align with the dictionary of the new
router) and also is going to add the logic that today is done in `Route`
(moving logic to `Routes` will be done in the follow-up PR, here I just
wanted to focus on using the common router components to make the review
process easier)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/150364
Fixes: https://github.com/elastic/sdh-kibana/issues/3806
Fixes a common complaint and bug where we limit the number of tags that
are displayed in the tags dropdown to 50. We now paginate these results
with a max tag of 10,000 (50 per page). It's not a true pagination
because Elasticsearch doesn't support filtering and paginating on
aggregation buckets (bucket selector doesn't work on terms). Since tags
are not nested properties or references, they can only be reached
through terms aggregation.
But at least we don't return 10000 tags from the API.
## How to test:
1. By default we show 50 tags per page, to make testing easier, you may
go to `x-pack/plugins/alerting/server/rules_client/methods/get_tags.ts`
and set `DEFAULT_TAGS_PER_PAGE` to 10 or something
2. Create some rules
3. Create some tags (spread amongst the rules would be even better)
4. Open the tag filter
5. Should be able to search, paginate, and filter rules by the tags
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Relates to:** https://github.com/elastic/security-team/issues/5308
## Summary
This PR make improvements and simplifications to `RulesListNotifyBadge` component exported by `triggers_actions_ui` plugin spotted during [adoption](https://github.com/elastic/security-team/issues/5308) of this component in Security Solution.
## Details
The list of the changes
- Mixed controlled and uncontrolled state has been resolved in favour of controlled state. It means an external code is responsible to fetch and provide rule snooze settings to the component.
- Loading state management has been moved inside the component. The only way to to set the component in loading state it to provide `undefined` for `snoozeSettings` input prop.
- Popover's open/close state management has been moved inside the component. I haven't noticed any problems in tables (Stack Management Rules and Security Solution Rules) if there are multiple rules are shown with `RulesListNotifyBadge` rendered. In attempt to open another snooze popover a previous one closes automatically.
- `rule` input prop has been renamed to `snoozeSettings`.
- `isEditable` field has been moved to a separate `disabled` prop. `disabled` can accept a string which is considered as a disabled reason and displayed in a tooltip. It's quite helpful to display for example fetching errors.
- `onRuleChanged` handler can return a promise so internal loading state persists until this promise resolved.
### Checklist
- [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials
- [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
- [x] Any UI touched in this PR is usable by keyboard only (learn more about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures (run axe in browser: [FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/), [Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive layout. (You can test this [in your browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
Resolves: #153755
This PR intends to make rule type param validation function required.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR:
- Moves the case bulk actions from the solutions to the alert table
- Refetch when using the case row actions & the case bulk actions.
- Renames the `kibana.alert.case_ids` label to `Cases`
- Unskip the `alerts_table.test.tsx` test file and skip the individual
flaky tests. I run the test file 60 times in the CI without any issues
(9efed89ee9)
- Renames the cases flyout and modal hook from `get*` to `use*`
Fixes: https://github.com/elastic/kibana/issues/151688
## Userflow
## Testing
### Alerts table
- The alerts table does not show the Cases column by default
- You can choose the case column from the fields modal. Type `Case` to
find the cases column
- The label of the column is `Cases`
- The label of the field in the fields modal is `Cases`
- You can bulk attach alerts to a new case
- You can bulk attach alerts to an existing case
- When bulk attaching alerts to a case the alerts table re-fetches the
data
- When attaching an alert to a case from the row actions the alerts
table re-fetches the data
### Case integrations outside the alerts table
- Ensure that you can attach your data to a case (existing and new)
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [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
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/153804
PR resolves issue by passing `SourceRequestMeta` to
`ITMSSource.getUrlTemplate`, giving `getUrlTemplate` the state needed to
update raster URL when required.
PR also resolves the following tech debt:
* rename `searchFilters` -> `requestMeta` to better reflect contents of
parameter.
* Map API's leak lots of implementation details. This PR took the time
to clean up one instance by moving `isGeoGridPrecisionAware` and
`getGeoGridPrecision` from `ISource` to `IESAggSource`
* moved `geogridPrecision` from `VectorSourceRequestMeta` into
`sourceMeta`.
* Removed `VectorJoinSourceRequestMeta` since its same as
`VectorSourceRequestMeta` now that `VectorSourceRequestMeta` does not
contain `geogridPrecision`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
👋 Hi all - the biggest breaking change of this PR is around two icon
type changes/renames.
1. ⚠️ **The `alert` icon is now named `warning`**
- <img width="103" alt=""
src="https://user-images.githubusercontent.com/549407/223561599-8913e88c-676f-47cd-aaed-81b64783bd81.png"
align="middle">
- This change should have been automatically converted on your behalf by
the EUI team, **but if for some reason** we missed making this
conversion in this PR and your icon(s) are now broken, please ping us or
let us know in this PR (or fix yourself after this PR merges).
- In some cases, teams were using this icon for error messages,
alongside the `danger` color. In those cases, we opinionatedly changed
those icon usages to the new `error` icon instead of using the old
alert/warning icon.
2. 🛑 **The `crossInACircleFilled` icon has been removed, and a new
`error` icon added**
- <img width="84" alt=""
src="https://user-images.githubusercontent.com/549407/223561892-4406bdf6-1a55-49ac-85ad-3a11eb7c090d.png"
align="middle">
- The conversion for this breaking change was not straightforward. This
was the path we used to determine what to change `crossInACircleFilled`
usages to:
- If the icon was associated with errors or error messages, we changed
it to the new `error` icon.
- If a "delete" action was associated with this icon, we changed it to
the `trash` icon instead.
- If a "clear" action was associated with this icon, we changed it to
just the `cross` icon, or in some cases `minusInCircleFilled` (if used
alongside `plusInCircleFilled`).
- Again, if we made a mistake during this conversion or missed your
plugin, please feel free to ping us.
## Summary
`eui@75.1.2` ⏩ `eui@76.0.2`
## [`76.0.2`](https://github.com/elastic/eui/tree/v76.0.2)
**Bug fixes**
- Added a legacy `alert` alias for the `warning` `EuiIcon` type
([#6640](https://github.com/elastic/eui/pull/6640))
## [`76.0.1`](https://github.com/elastic/eui/tree/v76.0.1)
**Bug fixes**
- Fixed broken icons on all `isInvalid` form controls
([#6629](https://github.com/elastic/eui/pull/6629))
## [`76.0.0`](https://github.com/elastic/eui/tree/v76.0.0)
- Added `pivot` glyph to `EuiIcon`
([#6605](https://github.com/elastic/eui/pull/6605))
- Added the `displayHeaderCellProps` API to `EuiDataGrid`'s columns,
which allows passing custom props directly to column header cells
([#6609](https://github.com/elastic/eui/pull/6609))
- Added the new `headerCellProps`/`footerCellProps` APIs to
`EuiDataGrid`'s control columns, which allows passing custom props
directly to control column header or footer cells
([#6609](https://github.com/elastic/eui/pull/6609))
- Added a new `footerCellRender` API to `EuiDataGrid`'s control columns,
which allows completely customizing control column rendering (previously
rendered an empty cell)
([#6609](https://github.com/elastic/eui/pull/6609))
- Updated the styling of nested ordered lists in `EuiText` to align with
GitHub's list style, which is a popular format used in Markdown or MDX
formatting ([#6615](https://github.com/elastic/eui/pull/6615))
- Added a margin-bottom property exclusively to the direct child `ul`
and `ol` elements of the `EuiText` component
([#6615](https://github.com/elastic/eui/pull/6615))
- Fix issue with badges appearing within an `EuiBadgeGroup`, where the
CSS rule to override the `margin-inline-start` was not being applied
correctly due to the order of appearance in the CSS rules
([#6618](https://github.com/elastic/eui/pull/6618))
**Bug fixes**
- Fixed `EuiDataGrid` footer control columns rendering with cell
expansion popovers when they should not have been
([#6609](https://github.com/elastic/eui/pull/6609))
- Fixed an `EuiSkipLink` bug where main content loading in
progressively/dynamically after the skip link rendered was not being
correctly focused ([#6613](https://github.com/elastic/eui/pull/6613))
**Breaking changes**
- Renamed `EuiIcon`'s `alert` to `warning`
([#6608](https://github.com/elastic/eui/pull/6608))
- Removed `EuiIcon`'s `crossInACircleFilled` in favor of `error`
([#6608](https://github.com/elastic/eui/pull/6608))
---------
Co-authored-by: Davey Holler <daveyholler@hey.com>
Co-authored-by: Constance Chen <constance.chen@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jon <jon@elastic.co>
## Summary
Resolves https://github.com/elastic/kibana/issues/137164.
This PR adds a new `revision` field (number) to Alerting Rules that
auto-increments when relevant content changes have been made via the
`Rules Client`. _Relevant content changes_ are defined as any content
change that the user may either want to be notified about, or have the
option to later revert to. This will include most all changes, except
the enabling/disabling of the rule, or updates to metadata fields like
`executionStatus` or `monitoring`. This `revision` field is not intended
to be user editable, and should be ignored if ever provided via the API.
See https://github.com/elastic/kibana/issues/136213 for additional
details. To be followed-up by
https://github.com/elastic/kibana/issues/137168, which will remove the
version bump logic from security solution.
## Details
### Migrations
Includes SO migration to default `revision` to `0` when upgrading a
cluster, or when importing `pre-8.8.0` rules via the SO Management UI.
For consistency, security rule import follows the same logic as SO
Management and will not reset the `revision` to `0` when overriding or
creating a new rule.
### Downstream Index Updates
* EventLog _has not_ been updated to include `revision` along with basic
rule fields currently being written. Should we?
* AAD Schema will be updated in
https://github.com/elastic/kibana/pull/151388 (as this one is getting
pretty big) to include `revision` so alerts written will include which
specific revision of the rule created the alert.
### Reference Fields
Any creation of or modification to `actions` will result in a revision
increment. More typical reference fields like `exception lists` on the
security side will only result in a revision increment when the list is
initially associated/deleted from the rule (as subsequent updates will
be done directly against the list).
### RuleClient Updates
The following methods within the RuleClient have been updated to support
incrementing revision when relevant field changes have been detected:
* `clone()` - resets to 0 currently (see open question)
* `update()` - increments `revision` so long a change has been made to
relevant fields (fields not in [ignore
list](https://github.com/elastic/kibana/pull/147398/files#diff-6736e143ede2dc06e825bddcdc23b4d088a6620805751db4eddc5900d586c4dfR69-R85))
* `bulkEdit()` - increments `revision` for relevant fields (all current
bulk edit fields minus api key/snooze/mute)
Mutation methods not updated to include revision log:
* `snooze()`
* `unsnooze()`
* `clearExpiredSnoozes()`
* `muteAll()`
* `unmuteAll()`
* `muteInstance()`
* `unmuteInstance()`
* `updateApiKey()` - increments revision as rule functionality could be
impacted
## Open questions:
- [X] Should `clone()` in RulesClient reset revision to 0 as if it's a
new rule, or keep the current value? (see
[comment](https://github.com/elastic/kibana/pull/147398/files#r1106484105))
- [X] What about snooze/un-snooze, and mute/unmute? Should we update
revision on these field changes as well? (see
[comment](https://github.com/elastic/kibana/pull/147398/files#r1106431966))
- Discussed with @XavierM and determined to not update on
snooze/mute/API key changes as this actions could be plentiful and don't
necessarily represent a version of the rule a user would want to revert
to, thus polluting the revision history.
- [ ] Should we write `revision` to EventLog?
---
### Checklist
Delete any items that are not applicable to this PR.
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] To work with docs team
- [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
### For maintainers
- [X] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
Resolves: https://github.com/elastic/kibana/issues/145132.
In this PR, I'm adding a new function to the server-side rule type
definition called `viewInAppRelativeUrl`. This function returns a
relative path to view the rule in the proper application that will
provide more context. This relative path is used to build the `rule.url`
mustache variable for the actions (overriding the rule details page link
when defined) as well as a fallback for the UI's `View in App` button if
no navigation is registered on the front-end.
Follow up issues:
- https://github.com/elastic/kibana/issues/149608
- https://github.com/elastic/kibana/issues/151355
## ML to verify
1. Create an anomaly detection rule from the ML application
2. Go to stack management rule details page
3. Click "View in App"
4. Ensure it brings you to the ML app properly.
5. Repeat step 1 to 4 in a space that isn't the default
Note: ML won't take advantage of the new functionality yet, but we plan
to help in a follow up https://github.com/elastic/kibana/issues/149608
so that ML anomaly detection rules can provide a view in app URL within
the rule action messages.
## ResponseOps to verify
1. Set `server.publicBaseUrl` to the proper value in your kibana.yml
6. Modify the [index threshold rule
type](https://github.com/elastic/kibana/blob/main/x-pack/plugins/stack_alerts/server/rule_types/index_threshold/rule_type.ts#L108-L136)
to have a `getViewInAppRelativeUrl` function returning
`/app/management/insightsAndAlerting/triggersActionsConnectors/connectors`.
7. Create an index threshold rule that always fires. Make sure to add a
a server log action that contains the `{{rule.url}}` variable.
8. Pull the printed URL from the server logs and make sure it works and
brings you to the connectors page.
9. Navigate to the rule details page, click the "View in App" button and
ensure it also brings you to the connectors page.
10. Create a Kibana space.
11. Go into that created space and repeat step 3 to 5. Ensure the URL
and View in App keep you in the same space.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR removes all imports of Route from react-router-dom and
'@kbn/kibana-react-plugin/public' and instead imports Route from
@kbn/shared-ux-router.
### Context
Based on
https://github.com/elastic/kibana/issues/132629#issue-1243243678 This PR
executes steps 2 - 4:
> 2. To make the transition easier, we want to re-export other
react-router-dom exports alongside the modified' Route'.
> 3. Solutions should start using that Route component in place of the
one from react-router-dom. I.e. replace all occurrences of import { ...
} from 'react-router-dom' with import { ... } from
'@kbn/shared-ux-router'.
> 4. All manual calls to useExecutionContext are not needed anymore and
should be removed.
### Future PR
Looks like this might be getting worked on in:
https://github.com/elastic/kibana/pull/145863 (thanks!)
> Introduce an ESlint rule that ensures that react-router-dom is not
used directly in Kibana and that imports go through the new
@kbn/shared-ux-router package.
This is tangentially accomplished through
https://github.com/elastic/kibana/pull/150340 but only addresses using
Route through @kbn/kibana-react-plugin/public'
### Checklist
Delete any items that are not applicable to this PR.
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Tiago Costa <tiagoffcc@hotmail.com>
Fixes https://github.com/elastic/kibana/issues/149344
This PR migrates all plugins to packages automatically. It does this
using `node scripts/lint_packages` to automatically migrate
`kibana.json` files to `kibana.jsonc` files. By doing this automatically
we can simplify many build and testing procedures to only support
packages, and not both "packages" and "synthetic packages" (basically
pointers to plugins).
The majority of changes are in operations related code, so we'll be
having operations review this before marking it ready for review. The
vast majority of the code owners are simply pinged because we deleted
all `kibana.json` files and replaced them with `kibana.jsonc` files, so
we plan on leaving the PR ready-for-review for about 24 hours before
merging (after feature freeze), assuming we don't have any blockers
(especially from @elastic/kibana-core since there are a few core
specific changes, though the majority were handled in #149370).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
We wanted to avoid duplication of code so we created a more integrated
component with API to snooze rule. we also added the information about
snooze in the task runner so security folks can manage their legacy
actions in the execution rule, it will looks like that
```ts
import { isRuleSnoozed } from '@kbn/alerting-plugin/server';
if (actions.length && !isRuleSnoozed(options.rule)) {
...
}
```
One way to integrated this new component in a EuiBasictable:
```
{
id: 'ruleSnoozeNotify',
name: (
<EuiToolTip
data-test-subj="rulesTableCell-notifyTooltip"
content={i18n.COLUMN_NOTIFY_TOOLTIP}
>
<span>
{i18n.COLUMN_NOTIFY}
<EuiIcon size="s" color="subdued" type="questionInCircle" className="eui-alignTop" />
</span>
</EuiToolTip>
),
width: '14%',
'data-test-subj': 'rulesTableCell-rulesListNotify',
render: (rule: Rule) => {
return triggersActionsUi.getRulesListNotifyBadge({
rule: {
id: rule.id,
muteAll: rule.mute_all ?? false,
activeSnoozes: rule.active_snoozes,
isSnoozedUntil: rule.is_snoozed_until ? new Date(rule.is_snoozed_until) : null,
snoozeSchedule: rule?.snooze_schedule ?? [],
isEditable: hasCRUDPermissions,
},
isLoading: loadingRuleIds.includes(rule.id) || isLoading,
onRuleChanged: reFetchRules,
});
},
}
```
I think Security solution folks might want/need to create a new io-ts
schema for `snooze_schedule` something like that should work:
```ts
import { IsoDateString } from '@kbn/securitysolution-io-ts-types';
import * as t from 'io-ts';
const RRuleRecord = t.intersection([
t.type({
dtstart: IsoDateString,
tzid: t.string,
}),
t.partial({
freq: t.union([
t.literal(0),
t.literal(1),
t.literal(2),
t.literal(3),
t.literal(4),
t.literal(5),
t.literal(6),
]),
until: t.string,
count: t.number,
interval: t.number,
wkst: t.union([
t.literal('MO'),
t.literal('TU'),
t.literal('WE'),
t.literal('TH'),
t.literal('FR'),
t.literal('SA'),
t.literal('SU'),
]),
byweekday: t.array(t.union([t.string, t.number])),
bymonth: t.array(t.number),
bysetpos: t.array(t.number),
bymonthday: t.array(t.number),
byyearday: t.array(t.number),
byweekno: t.array(t.number),
byhour: t.array(t.number),
byminute: t.array(t.number),
bysecond: t.array(t.number),
}),
]);
export const RuleSnoozeSchedule = t.intersection([
t.type({
duration: t.number,
rRule: RRuleRecord,
}),
t.partial({
id: t.string,
skipRecurrences: t.array(t.string),
}),
]);
```
### 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
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/148760
Makes the rules setting link that opens up the flapping settings modal
shareable from the `triggers_action_ui` plugin (`getRulesSettingsLink`).
Also adds storybook entires for this component (`rulesSettingsLink`).
To view locally, run `yarn storybook triggers_actions_ui`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Xavier Mouligneau <xavier.mouligneau@elastic.co>
This PR upgrades uuid into its latest version `9.0.0`.
The previous default used version `v4` was kept where it was previously
used and places using `v1` or `v5` are still using it.
In this latest version they removed the deep import feature and as we
are not using tree shaking it increased our bundles by a significant
size. As such, I've moved this dependency into the `ui-shared-deps-npm`
bundle.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
In this PR, I'm changing the return type of rule executors from `return
state;` to `return { state };`.
This change had to touch all rule type executors so they return `state`
as a key. In the future, the framework could accept more than `state` in
the object, like warnings as an example.
**Before:**
```
executor: async (...) {
const state = {...};
return state;
}
```
**After:**
```
executor: async (...) {
const state = {...};
return { state };
}
```
**Future:**
```
executor: async (...) {
return {
state: {...},
warnings: [...],
metrics: {...},
...
};
}
```
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- Removes `UiComponent` and its usages.
- Fixes UI Actions TypeScript types.
### Checklist
Delete any items that are not applicable to this PR.
- [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
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Anton Dosov <dosantappdev@gmail.com>
Co-authored-by: Dima Arnautov <arnautov.dima@gmail.com>
## Dearest Reviewers 👋
I've been working on this branch with @mistic and @tylersmalley and
we're really confident in these changes. Additionally, this changes code
in nearly every package in the repo so we don't plan to wait for reviews
to get in before merging this. If you'd like to have a concern
addressed, please feel free to leave a review, but assuming that nobody
raises a blocker in the next 24 hours we plan to merge this EOD pacific
tomorrow, 12/22.
We'll be paying close attention to any issues this causes after merging
and work on getting those fixed ASAP. 🚀
---
The operations team is not confident that we'll have the time to achieve
what we originally set out to accomplish by moving to Bazel with the
time and resources we have available. We have also bought ourselves some
headroom with improvements to babel-register, optimizer caching, and
typescript project structure.
In order to make sure we deliver packages as quickly as possible (many
teams really want them), with a usable and familiar developer
experience, this PR removes Bazel for building packages in favor of
using the same JIT transpilation we use for plugins.
Additionally, packages now use `kbn_references` (again, just copying the
dx from plugins to packages).
Because of the complex relationships between packages/plugins and in
order to prepare ourselves for automatic dependency detection tools we
plan to use in the future, this PR also introduces a "TS Project Linter"
which will validate that every tsconfig.json file meets a few
requirements:
1. the chain of base config files extended by each config includes
`tsconfig.base.json` and not `tsconfig.json`
1. the `include` config is used, and not `files`
2. the `exclude` config includes `target/**/*`
3. the `outDir` compiler option is specified as `target/types`
1. none of these compiler options are specified: `declaration`,
`declarationMap`, `emitDeclarationOnly`, `skipLibCheck`, `target`,
`paths`
4. all references to other packages/plugins use their pkg id, ie:
```js
// valid
{
"kbn_references": ["@kbn/core"]
}
// not valid
{
"kbn_references": [{ "path": "../../../src/core/tsconfig.json" }]
}
```
5. only packages/plugins which are imported somewhere in the ts code are
listed in `kbn_references`
This linter is not only validating all of the tsconfig.json files, but
it also will fix these config files to deal with just about any
violation that can be produced. Just run `node scripts/ts_project_linter
--fix` locally to apply these fixes, or let CI take care of
automatically fixing things and pushing the changes to your PR.
> **Example:** [`64e93e5`
(#146212)](64e93e5806)
When I merged main into my PR it included a change which removed the
`@kbn/core-injected-metadata-browser` package. After resolving the
conflicts I missed a few tsconfig files which included references to the
now removed package. The TS Project Linter identified that these
references were removed from the code and pushed a change to the PR to
remove them from the tsconfig.json files.
## No bazel? Does that mean no packages??
Nope! We're still doing packages but we're pretty sure now that we won't
be using Bazel to accomplish the 'distributed caching' and 'change-based
tasks' portions of the packages project.
This PR actually makes packages much easier to work with and will be
followed up with the bundling benefits described by the original
packages RFC. Then we'll work on documentation and advocacy for using
packages for any and all new code.
We're pretty confident that implementing distributed caching and
change-based tasks will be necessary in the future, but because of
recent improvements in the repo we think we can live without them for
**at least** a year.
## Wait, there are still BUILD.bazel files in the repo
Yes, there are still three webpack bundles which are built by Bazel: the
`@kbn/ui-shared-deps-npm` DLL, `@kbn/ui-shared-deps-src` externals, and
the `@kbn/monaco` workers. These three webpack bundles are still created
during bootstrap and remotely cached using bazel. The next phase of this
project is to figure out how to get the package bundling features
described in the RFC with the current optimizer, and we expect these
bundles to go away then. Until then any package that is used in those
three bundles still needs to have a BUILD.bazel file so that they can be
referenced by the remaining webpack builds.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* Add legends to custom map layers and convert wms_source to typescript
Co-authored-by: Sean Sullivan <ssullivan@spectric.com>
Co-authored-by: Nick Peihl <nickpeihl@gmail.com>
