## Summary
Issue: https://github.com/elastic/kibana/issues/179105
Related PR: https://github.com/elastic/kibana/pull/180539
Part 1: https://github.com/elastic/kibana/pull/183325
Part 2 of 3 PRs of new rule form. This PR depends on the code from part
1, so only merge this when part 1 has been merged. This PR extracts the
last section of the rule form, the rule details, from the original PR.
The design philosophy in the PR is to create components that are devoid
of any fetching or form logic. These are simply dumb components.
I have also created a example plugin to demonstrate this PR. To access:
1. Run the branch with yarn start --run-examples
2. Navigate to
http://localhost:5601/app/triggersActionsUiExample/rule_details
And you should be able to play around with the components in this PR:
<img width="1281" alt="Screenshot 2024-05-13 at 9 44 14 PM"
src="7ca900e3-ca9a-4810-8b24-7c3ea41055d6">
### 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: Zacqary <zacqary.xeper@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Issue: https://github.com/elastic/kibana/issues/179105
Related PR: https://github.com/elastic/kibana/pull/180539
Part 1 of 3 PRs of new rule form. This PR extracts the first section of
the rule form, the rule definition, from the original PR. The purpose is
to fix a few bugs (Such as improving the alert delay and the rule
schedule input validation), and also try to make the PR much smaller for
review. The design philosophy in the PR is to create components that are
devoid of any fetching or form logic. These are simply dumb components.
I have also created a example plugin to demonstrate this PR. To access:
1. Run the branch with `yarn start --run-examples`
2. Navigate to
`http://localhost:5601/app/triggersActionsUiExample/rule_definition`
And you should be able to play around with the components in this PR:
<img width="1257" alt="Screenshot 2024-05-13 at 10 10 51 AM"
src="a1ab6d96-946d-4bf6-94e2-6aa903d0b8f5">
### 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: Zacqary <zacqary.xeper@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes needed for getting CI to pass when EUI throws an error if
attempting to render a component without the EuiProvider in the render
tree.
## Detailed description
In https://github.com/elastic/kibana/pull/180819, I will deliver a
change that will cause EUI components to throw an error if the
EuiProvider context is missing. This PR comes in as part of the final
work to get all functional tests passing in an environment where EUI
will throw the error. The tied to the ["Fix 'dark mode' inconsistencies
in Kibana" Epic](https://github.com/elastic/kibana-team/issues/805) has
so far been in preparation for this.
**Reviewers: Please interact with critical paths through the UI
components touched in this PR, ESPECIALLY in terms of testing dark mode
and i18n.**
<img width="1107" alt="image"
src="c0d2ce08-ac35-45a7-8192-0b2256fceb0e">
### 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
- [ ] 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)
## Summary
Fixes needed for getting CI to pass when EUI throws an error if
attempting to render a component without the EuiProvider in the render
tree.
## Detailed description
In https://github.com/elastic/kibana/pull/180819, I will deliver a
change that will cause EUI components to throw an error if the
EuiProvider context is missing. This PR comes in as part of the final
work to get all functional tests passing in an environment where EUI
will throw the error. The tied to the ["Fix 'dark mode' inconsistencies
in Kibana" Epic](https://github.com/elastic/kibana-team/issues/805) has
so far been in preparation for this.
**Reviewers: Please interact with critical paths through the UI
components touched in this PR, ESPECIALLY in terms of testing dark mode
and i18n.**
<img width="1107" alt="image"
src="c0d2ce08-ac35-45a7-8192-0b2256fceb0e">
### 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
- [ ] 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)
## Summary
Fixes needed for getting CI to pass when EUI throws an error if
attempting to render a component without the EuiProvider in the render
tree.
## Detailed description
In https://github.com/elastic/kibana/pull/180819, I will deliver a
change that will cause EUI components to throw an error if the
EuiProvider context is missing. This PR comes in as part of the final
work to get all functional tests passing in an environment where EUI
will throw the error. The tied to the ["Fix 'dark mode' inconsistencies
in Kibana" Epic](https://github.com/elastic/kibana-team/issues/805) has
so far been in preparation for this.
**Reviewers: Please interact with critical paths through the UI
components touched in this PR, ESPECIALLY in terms of testing dark mode
and i18n.**
<img width="1107" alt="image"
src="c0d2ce08-ac35-45a7-8192-0b2256fceb0e">
### 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
- [ ] 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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Prep work for React@18 bump
tl;dr In React@18 `React.FC` doesn't contain `children` anymore, so in
order to make the bump easier I have decided to split the effort in
multiple faces and hopefully this will make it easier for everyone
This PR focuses only on adding explicit `children` declaration either by
using `React.PropsWithChildren` type or by adding `children:
React.ReactNode` to the existing props types
https://github.com/DefinitelyTyped/DefinitelyTyped/issues/46691
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Sergi Massaneda <sergi.massaneda@gmail.com>
Co-authored-by: Marco Vettorello <marco.vettorello@elastic.co>
Co-authored-by: James Gowdy <jgowdy@elastic.co>
## Summary
This PR refactors https://github.com/elastic/kibana/pull/179206 to have
each export type be registered in Reporting and then passed into the
share plugin.
This PR is focused on the redesign in terms of the export modals. Test
refactoring will be done in a separate PR.
Partially closes https://github.com/elastic/kibana-team/issues/753
- [x] Need to refactor this PR to include @eokoneyo's general modal
component
- [x] Lens needs to have Export with all three report type options - to
avoid circular dependencies move the Lens CSV stuff into the reporting
plugin vs having it in Lens
- [x] Canvas should not be affected by these changes (so the old
share/reporting code has to stay for canvas)
https://github.com/elastic/kibana/issues/151523 to keep in mind for the
redesign
Failed tests will be covered in this PR
https://github.com/elastic/kibana/pull/180406
### TO TEST
Mark `share.new_version.enabled: true` in your kibana.dev.yml
### Checklist
- [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] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
---------
Co-authored-by: Eyo Okon Eyo <eyo.eyo@elastic.co>
Co-authored-by: Tim Sullivan <tsullivan@users.noreply.github.com>
Co-authored-by: Marco Liberati <dej611@users.noreply.github.com>
## Summary
This pr makes use of a new prop (and some generic memoization fixes) in
2 eui prs merged recently (https://github.com/elastic/eui/pull/7556 and
https://github.com/elastic/eui/pull/7374) to improve the performance of
the alerts table. Mainly, the cellContext prop is now available to
consumers of the triggersActionsUi alerts table to pass in custom props
in a way that allows the renderCellValue/rowCellRender functions of the
various EuiDataGrid prop apis to remain referentially stable across
re-renders. There are also some various changes to various hooks and
props found throughout plugins that use the table to improve
performance. There should be no change in functionality, just a moderate
to substantial reduction in time the app spends rendering the alerts
table in various scenarios. Below will be some react dev tools
performance profiles, main compared to this branch, with the exact same
set of generated data.
Main, switching from 10-100 rows:
This branch 10-100 rows:
Pretty modest gain here, 1 render is slower than any others on main, but
overall less time spent rendering by about a second.
Main, opening the cell popover on 2 cells
This branch, opening cellpopover
Again nothing crazy here, modest improvement.
Main opening timeline and hitting refresh
This branch, opening timeline and hitting refresh
This is the case that brought this about in the first place, as security
solution shares a lot of code between tables, the alerts table
recreating all cells on every render was destroying performance of the
timeline rendering in a flyout/modal while users were on alerts page or
the rule detail page, which is probably the most common use case. 93ms
in this branch vs 2500+ ms in main. This type of performance hit happens
when almost any action is taken in timeline.
Main, selecting 3 alerts 1 at a time
This branch selecting 3 alerts 1 at a time
Pretty substantial improvement here as well, ~2000ms vs 67ms.
Apologies if some of the gifs are cut off, please try the branch vs main
on your own! This was done on a local kibana in dev mode, so things like
emotion are eating up more cpu than they would for a user, but there
still should be improvement, and I can't think of any circumstance where
things will be worse. Also this branch was a little longer lived than I
would have liked, so if you are reviewing and changed something around
these files recently please double check I didn't miss anything.
### 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
## Summary
A system action is an action that triggers Kibana workflows—for example,
creating a case, running an OsQuery, running an ML job, or logging. In
this PR:
- Enable rule routes to accept system actions. The schema of the action
is not changed. The framework deducts which action is a system action
automatically. System actions do not accept properties like the
`notifyWhen` or `group`.
- Enable rule client methods to accept system actions. The methods
accept a new property called `systemActions`. The methods merge the
actions with the system actions before persisting the rule to ES. The
methods split the actions from the system actions and return two arrays,
`actions` and `systemActions`.
- Introduce connector adapters: a way to transform the action params to
the corresponding connector params.
- Allow the execution of system actions. Only alert summaries are
supported. Users cannot control the execution of system actions.
- Register an example system action.
- Change the UI to handle system action. All configuration regarding
execution like "Run when" is hidden for system actions. Users cannot
select the same system action twice.
Closes https://github.com/elastic/kibana/issues/160367
This PR merges the system actions framework, a culmination of several
issues merged to the `system_actions_mvp` feature branch over the past
several months.
## Testing
A system action with ID `system-connector-.system-log-example` will be
available to be used by the APIs and the UI if you start Kibana with
`--run-examples`. Please ensure the following:
- You can create and update rules with actions and system actions.
- A rule with actions and system actions is executed as expected.
- Entries about the system action execution are added to the event log
as expected.
- Existing rules with actions work without issues (BWC).
- You can perform bulk actions in the rules table to rules with actions
and system actions.
- License restrictions are respected.
- Permission restrictions are respected.
- Disabled system actions cannot be used.
- Users cannot specify how the system action will run in the UI and the
API.
### Checklist
- [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
- [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))
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Julia <iuliia.guskova@elastic.co>
Co-authored-by: Zacqary Xeper <zacqary.xeper@elastic.co>
Co-authored-by: Zacqary Adam Xeper <Zacqary@users.noreply.github.com>
Co-authored-by: Ying Mao <ying.mao@elastic.co>
Co-authored-by: Xavier Mouligneau <xavier.mouligneau@elastic.co>
## Summary
For ES|QL charts the formula api should be redundant. This is going to
make the api lighter as there is no need to import the lens plugin if
you want to use the builder to create ES|QL charts.
Part of https://github.com/elastic/kibana/issues/175138 and prerequisite
for https://github.com/elastic/kibana/issues/174960
PR decouples Url drilldown action from Embeddable framework by migrating
to sets of composable interfaces.
### test instructions
1. Create panel and add "Url drilldown"
2. Verify `context` variables are populated with the same values when
they were grabbed from embeddable.input and embeddable.output
<img width="600" alt="Screenshot 2024-01-31 at 2 11 20 PM"
src="150f7a61-911f-4fb6-bf85-5c0481865e4b">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
While implementing `IESSource` interface with ES|QL source, I discovered
that `ISource` and `IESSource` interfaces produce a confusing
combination of methods. `ISource` interface has `getIndexPatternIds` and
`getQueryableIndexPatternIds` methods. The more specific `IESSource`
interface has `getIndexPatternId` method. Having `getIndexPatternIds`
and `getIndexPatternId` on the same class is confusing.
PR removes `getIndexPatternIds` and `getQueryableIndexPatternIds`
methods from `ISource` and uses type guards to call
`IESSource.getIndexPatternId` where appropriate.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
PR replaces `ISource.isESSource` method with type guards for IESSource
interface. This provides stronger type guards and paves the way for
addition ES|QL map layer work (ES|QL layers providing geoFieldNames and
data views).
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Initial part of https://github.com/elastic/kibana/issues/131852
This PR moves towards auto-calculating the maximum timeouts calculated
based on the timing context provided by the running task instance.
### Other changes
* Added an optional logger parameter to the `getScreenshots` function.
When a logger is provided, the logs created by the screenshot plugin
will have the contextual tags added by the calling code.
* Before
<img width="1198" alt="image"
src="f68a102e-6af2-4863-aedb-52f1e4a099d8">
* After
<img width="1200" alt="image"
src="2dd4c947-ffa6-4cb3-b8a2-22893f49ddb7">
* Fixed an unreported bug where browser timezone was not utilized in PNG
reports.
### 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
## Summary
The multi-panel flyout didn't allow the user to scroll the editing
controls. All better now 🩹b06996de-62ba-431a-9cb1-eb3c20be42ee
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Towards https://github.com/elastic/response-ops-team/issues/164
## Summary
Registering alerting example rules with framework AAD. This creates a
new alerts index `.alerts-default.alerts-default` that will eventually
hold alerts for all rules that have not customized their registration.
This index contains only the mappings for the basic alerts as data
documents, no custom context or payload fields.
## To Verify
Run kibana using `--run-examples` flag. Create one of the example rule
types and let it alert and then resolve and see an alert document get
created in the `.alerts-default.alerts-default` index.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR removes the legacy kibana react code-editor, alongside replacing
all import declarations of this legacy component to the one offered by
shared-ux, i.e import declaration source of `'@kbn/kibana-react/public'`
is switched to `@kbn/code-editor`.
Also in this PR an helper for writing jest tests has been included
through the package `@kbn/code-editor-mock`, this would facilitate
mocking the editor, especially given that the code editor leverages
couple of APIs that are aren't included by default in jsdom, among them,
`matchMedia`, `ResizeObserver`. The provided mock is sufficient for most
use cases and can be setup in any package within kibana as a
[`node_module`
mock](https://jestjs.io/docs/manual-mocks#mocking-node-modules) without
having to repeatedly manually mock the editor within individual test
files. An example for how this might be done can be found here
ec5ba25368
### 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)
-->
- [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
<!--
- [ ] 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>
## Summary
Closes https://github.com/elastic/kibana/issues/167632
This PR provides a simpler api for the Lens embeddable consumers who
want to provide inline editing capabilities. I added an example to help
with the integration. Run kibana with
```
yarn start --run-examples
```
http://localhost:5601/app/lens_embeddable_inline_editing_example
<img width="1381" alt="image"
src="58e7ef2d-2f92-4bab-9cb4-d04a90d87e15">
<img width="2498" alt="image"
src="0a050e8d-f22f-4c48-88e4-20c42683a279">
It also allows the consumers to render the inline editing component in a
custom element in case you don't want to open a push flyout.
I included a readme on how to use the api.
### Note
This is the first PR which uses the new Lens config builder so some of
the changes are not related to the api improvements but they are fixing
some bugs on the builder.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
https://github.com/openai/openai-node/releases/tag/v4.0.0
For reviewers: I made a first pass, but I'm unsure on a few of the
checks. If there's a ts-expect-error help would be appreciated. Feel
free to push directly or whichever workflow is best for you.
---------
Co-authored-by: Dario Gieselaar <dario.gieselaar@elastic.co>
## Summary
Add a mute/unmute action component to be used in alerts table row
actions, move all common alerts table row actions to triggersActionsUI
and re-export them for consumers to compose their table actions.
### Checklist
- [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
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
---------
Co-authored-by: Xavier Mouligneau <xavier.mouligneau@elastic.co>
Co-authored-by: Maryam Saeidi <maryam.saeidi@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR refactors the export type classes into their own packages to be
then instantiated in the reporting plugin. This will reduce bloat in the
central reporting plugin.
**Main packages**
- `kbn/reporting-export-types-{png,pdf,csv}` are server packages with
export type declarations
- `kbn/reporting-export-types-{png,pdf,csv}-common` are shared common
packages with type declarations and constants
**Other changes**
- Remove `reporting.getScreenshots()`
- Remove duplicated `schema_utils.ts`
- Consolidate `JOB_STATUS` declaration as an enum
<img width="1063" alt="image"
src="bced8321-93c5-4ebd-b31e-1fd946166241">
### Checklist
- [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: Timothy Sullivan <tsullivan@elastic.co>
## Summary
This PR removes the [duplicated RedirectAppLinks
component](https://github.com/elastic/kibana/blob/v8.10.4/src/plugins/kibana_react/public/app_links/redirect_app_link.tsx)
which has been marked as deprecated since
74a00fad20.
All references to the previous import declaration from
`@kbn/kibana-react-plugin/public` have been replaced with
`@kbn/shared-ux-link-redirect-app`, this change ensures that the current
app behaviour is preserved, and changes to match the expectation of the
new component have been applied where necessary.
Changes relating to the new `RedirectAppLinks` component;
- The component does not accept a `className` anymore as it is not a
presentational component despite it being used as one previously,
there's change to make accommodation for how it had been used.
- The component introduces a`data-test-subj` attribute with the value
`kbnRedirectAppLink` on the dom node that wraps it's children.
### 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)~
-->
- [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
<!--
~- [ ] 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>
Updates new teams as codeowners for Observability team changes.
Also took the opportunity to:
- Delete some paths that no longer exist
- Split infra code ownership between teams (from #168992)
## Summary
Improve rule interval circuit breaker error message to the following
endpoints:
- create
- update
- bulk edit
- bulk enable
### Bulk modification
### Modifying a single rule
### 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>
Co-authored-by: Xavier Mouligneau <xavier.mouligneau@elastic.co>
## Summary
> Note: I strongly recommending [viewing the diff with whitespace
changes turned
off](https://github.com/elastic/kibana/pull/168300/files?w=1), as many
of the "changes" are simply indentation changes.
EUI will shortly be removing several deprecated `EuiPage*` components,
and we're updating a few remaining Kibana usages of these deprecated
components ahead of time.
⚠️ PLEASE NOTE: We have **not** QA'd these changes to ensure that the UI
is 1:1 from before. We do not have the domain knowledge or time to spin
up local instances of all plugins with deprecations, and ask that the
CODEOWNING team pull down this branch and QA the affected page(s)
locally to ensure the UI looks like the same as production. ⚠️
See https://github.com/elastic/kibana/issues/161872 for other similar
tasks with more information about this effort.
## 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>
