Address https://github.com/elastic/kibana/issues/216061
Adds an indirection layer in the definition of the `transformFn:`, which
forces devs to explicitly define the types of the documents being
transformed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This fixes a few super small issues with the config settings files:
- Fixes an outdated Asciidoc remnant in our "Alert and Actions settings"
PoC file
- Adds a page-level ID in the sample file and the readme
- Fixes up the readme
- Removes unneeded quotation marks from one value in the PoC file.
# Summary
This PR merges Threat Intelligence plugin with security solution, in
order to remove duplicated and unnecessary code introduced as a bridge
between the TI plugin and Security Solution + to simpify maintenance. No
new functionality is implemented here, other than changing imports and
some dependendies to use security solution code directly, without weird
bridges or hacks / indirections.
## Testing
Navigate to threat intelligence plugin / indicators and try clicking
around. It is hard to list every feature we have there
but in general it should work without errors.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
/!\ Merge on release day
This PR adds release notes for the 9.0.2 release of Kibana.
Please check that listed items are correct and that nothing major is
missing.
Closes: https://github.com/elastic/platform-docs-team/issues/680
---------
Co-authored-by: wajihaparvez <wajiha.parvez@elastic.co>
## Summary
Implements the onechat tool registry RFC.
Fix https://github.com/elastic/search-team/issues/9938
Fix https://github.com/elastic/search-team/issues/10019
This PR introduces the following artifacts:
**plugins:**
- `onechat`
**packages:**
- `@kbn/onechat-common`
- `@kbn/onechat-server`
- `@kbn/onechat-browser`
## Tool APIs overview
### Registering a tool
```ts
class MyPlugin {
setup(core: CoreSetup, { onechat }: { onechat: OnechatPluginSetup }) {
onechat.tools.register({
id: 'my_tool',
name: 'My Tool',
description: 'My very first tool',
meta: {
tags: ['foo', 'bar'],
},
schema: z.object({
someNumber: z.number().describe('Some random number'),
}),
handler: ({ someNumber }, context) => {
return 42 + someNumber;
},
});
}
}
```
### Executing a tool
Using the `execute` API:
```ts
const { result } = await onechat.tools.execute({
toolId: 'my_tool',
toolParams: { someNumber: 9000 },
request,
});
```
Using a tool descriptor:
```ts
const tool = await onechat.tools.registry.get({ toolId: 'my_tool', request });
const { result } = await tool.execute({ toolParams: { someNumber: 9000 } });
```
With error handling:
```ts
import { isToolNotFoundError } from '@kbn/onechat-common';
try {
const { result } = await onechat.tools.execute({
toolId: 'my_tool',
toolParams: { someNumber: 9000 },
request,
});
} catch (e) {
if (isToolNotFoundError(e)) {
throw new Error(`run ${e.meta.runId} failed because tool was not found`);
}
}
```
### Listing tools
```ts
const tools = await onechat.tools.registry.list({ request });
```
*More details and example in the plugin's readme.*
### What is **not** included in this PR:
- tool access control / authorization - we have a dedicated RFC
- dynamic tool registration / permissions checks part/of depends on the
authorization RFC
- feature / capabilities - will come with browser-side and HTTP APIs
- fully defining tool meta - hard to do now
- filter parameters for the tool list API - depends on the meta being
defined
*Those will be follow-ups*. Everything else from the RFC should be
there.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This outdated settings file could cause some confusion so let's remove
it.
The newer `kibana-alert-action-settings.yml` will be used to generated
settings docs.
## Summary
This PR aims to answer questions about the implementation details for
https://github.com/elastic/kibana-team/issues/1328
We'd like to trigger an intercept dialog to users at specific time
intervals that vary and depend on different parameters, see the PRD
linked in the aforementioned issue.
This MVP takes an approach such that the constraints listed below are
resolved;
- Have the intercept be specific to a single user
- Define a strategy to configure triggers that can vary for the
intercept that's not dependent on the client
How does this work?
- A generic plugin has been created which when declared as dependency
can be used to register and schedule an intercept that should be
presented to the user, this plugin is what's been used for the product
intercept dialog.
- To handle rendering the UI component that gets displayed to the users,
in this PR we hook into core's existing notification system, through the
notification coordinator system that's been created so that we don't
have a situation where an intercept is being displayed whilst a user
might have a toast being rendered to them, if there's an intercept to be
displayed said intercept would not be displayed till the user is
completely done interacting with the toast. [See it's implementation
details
here](src/core/packages/notifications/browser-internal/src/notification_coordinator.ts)
and
[here](x-pack/platform/plugins/private/intercepts/public/prompter/service/intercept_dialog_service.tsx)
for how it's integrated.
- The plugin provides some bootstrap data through an endpoint that every
user calls on page load, ideally this would need to happen just the once
on page load, we then compute when a user should see a trigger
leveraging the bootstrap data provided for the particular registered
trigger in question, the returned data returns the following data as
seen below;
<img width="476" alt="Screenshot 2025-03-27 at 18 01 12"
src="https://github.com/user-attachments/assets/c747b6c8-70d0-4305-b555-ec9998b180c1"
/>
Given we have this data we might then have a flow for triggering the
intercept on the client based of the bootstrap data like so;
```mermaid
flowchart TD
A[State Bootstrap] --> B{Has data?}
B -->|No| C(Do Nothing)
B -->|Yes| D{Does computed runs since trigger registration match stored
user trigger run feedback value?}
D -->|No| E[setup timer to display an intercept in that time]
E -->|on completion| G[setup interval to display intercept in the
future]
D -->|Yes| G
G -->|repeat| G
```
reloading the page restarts the entire process.
## Telemetry
The intercept component provided by defaults records telemetry for
intercept registration, acknowledgement (differentiated into dismissal
and completion), alongside registration overload.
## Visuals
<!--
https://github.com/user-attachments/assets/b39a506c-a119-40e8-9152-258d78691f28
-->
<!--
https://github.com/user-attachments/assets/f564b4bc-9ad9-4e19-8158-6e154ef52fc2
-->
<img width="738" alt="Screenshot 2025-05-07 at 19 41 23"
src="https://github.com/user-attachments/assets/902c6d0b-9299-44bd-8808-4ad97227d0da"
/>
## Testing this PR
- Pull this branch to your machine
- Add the following to your `kibana.dev.yml`, to enable the intercept to
run and be visible
```yml
xpack.intercepts.enabled: true
xpack.product_intercept.enabled: true
xpack.product_intercept.interval: '30s'
```
<!--
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] 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/src/platform/packages/shared/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
- [ ] 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 was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
-->
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Release Notes
Kibana logging's pattern layout, used by default for the console
appender, will now use a new default pattern layout
`[%date][%level][%logger] %message %error`. This will include the error
name and stack trace if these were included in the log entry. To opt out
of this behavior users can omit the `%error` placeholder from their log
pattern config in kibana.yml e.g.:
```
logging:
appenders:
console:
type: console
layout:
type: pattern
pattern: "[%date][%level][%logger] %message"
```
## Summary
Previously, when we pass the error in meta, the information related to
stacktrace and error message was not available in console. This PR
changed the default pattern to also include error information if it is
provided in meta (similar to the way that the logging happens when error
is directly passed to logger.error).
New pattern: (added `%error` at the end)
```
[%date][%level][%logger] %message %error
```
Here you can see the difference:
Logger:
```
server.logger.error(
`Unable to create Synthetics monitor ${monitorWithNamespace[ConfigKey.NAME]}`,
{ error: e }
);
```
#### Before
#### After
### Alternative
We could also change the MetaConversion and include this information,
but we might have additional meta information which I am not sure if it
is OK to be logged by default. Let me know if you prefer changing
MetaConversion instead of adding a new error conversion.
<details>
<summary>Code changes for MetaConversion</summary>
```
function isError(x: any): x is Error {
return x instanceof Error;
}
export const MetaConversion: Conversion = {
pattern: /%meta/g,
convert(record: LogRecord) {
if (!record.meta) {
return '';
}
const { error, ...rest } = record.meta;
const metaString = Object.keys(rest).length !== 0 ? JSON.stringify(rest) : '';
let errorString = '';
if (isError(record.meta?.error)) {
errorString = record.meta?.error.stack || '';
}
return [metaString, errorString].filter(Boolean).join(' ');
},
};
```
</details>
Here is how adjusting meta will look like in this case:
Behavioral analytics was hidden from the UI and its associated APIs were
deprecated in 9.0, but only the API deprecation was called out in
Elasticseach release notes. This PR addresses the UI communication gap
by adding a mention to the 9.0 breaking changes (while it's technically
a deprecation, the fact that it's been hidden in Kibana makes it look
more like a breaking change from a customer perspective).
Rel: https://github.com/elastic/docs-content/issues/1417
Rel: https://github.com/elastic/kibana/pull/212031
Updating release notes for 9.0.1 (docs V3) in main branch.
Not sure how we plan to deal with the security advisor messages in the
release notes in the new docs system, considering the release notes page
include a generic message at the beginning pointing to the security
advisory board.
Also I'm not totally sure if this needs to be merged into any other
branch, I'll let @wajihaparvez and @florent-leborgne to determine how
this should be done, and approve or reject the PR.
## Summary
Part of #218501
This PR removes the advanced setting
`observability:enableInfrastructureAssetCustomDashboards` but keeps the
saved object, to be removed in a [follow-up
issue](https://github.com/elastic/kibana/issues/220340).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR updates some remaining obsolete variables and mentions of
ESS/Elasticsearch Service that should now refer to Elastic Cloud Hosted.
Note: There are still a few valid references to the Elasticsearch
service, not to be mixed with the cloud offering bearing the same name.
## Summary
This PR implements support for Lens chart fetches across Discover tabs,
and restoring chart state when returning to a tab.
The Lens embeddable does not currently support continuing data fetching
after it's been unmounted, or fully support restoring chart state using
previously fetched data. The Vis team is aware of this request, but in
the meantime we're using an alternative approach that keeps Lens charts
rendered in memory for each tab that's been visited at least once. This
allows fetches to run in the background and displays the resulting chart
when switching back to tabs. Doing this involved some refactoring to
both Discover and Unified Histogram:
- Create a `ChartPortalsRenderer` wrapper component in Discover to lift
chart rendering high up in the React tree and render charts into
[reverse portals](https://github.com/httptoolkit/react-reverse-portal),
ensuring charts are not remounted when switching tabs and continue to be
rendered after switching away from a tab.
- Refactor Unified Histogram from a single "container" component into
three pieces: a `UnifiedHistogramLayout` component, a
`UnifiedHistogramChart` component, and a `useUnifiedHistogram` hook to
tie things together. This approach allows us to render the chart and
hook separately (in a reverse portal) from the layout, making it
possible to separate the lifecycle of both components without keeping
the rest of Discover's components in memory after switching tabs.
- **Important note:** This change had the side effect of bloating the
Unified Histogram page load bundle since we're now exporting a static
hook that isn't dynamically imported. We could have worked around this
by getting creative with dynamic imports, but doing that seemed hacky.
Instead I decided now was a good time to split Unified Histogram out
into a package in order to support tree shaking, which also has the
added benefits of one fewer plugins to load on startup, and simplifying
the Discover async bundles.
There is one flaw with this approach: the `useDiscoverHistogram` hook
currently depends on global services for retrieving the current query
and filters (including global filters) through the `useQuerySubscriber`
hook. This means the values can become out of sync in inactive tabs when
the user modifies them in the current tab. In practice this doesn't seem
to have an effect in most cases since we don't trigger new fetches in
inactive tabs, and sync the the current tab values to the global
services when switching back to a tab. However, we should still fix this
for the MVP with an approach that doesn't leak state since the current
approach is brittle. I avoided doing that in this PR since it would
likely cause more conflicts with #217706, and that PR may introduce a
solution to the issue anyway (syncing global state to the redux store,
which we can rely on in the hook instead).
Resolves#216475.
### Checklist
- [ ] 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/src/platform/packages/shared/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
- [ ] 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)
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](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
Updated the transform plugin's `README.md` with some more details.
Updates CODEOWNERS for transforms so `elastic/ml-ui` and
`elastic/kibana-management` are both code owners.
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
