## Summary
Fixes https://github.com/elastic/security-team/issues/8934
Summarize your PR. If it involves visual changes include a screenshot or
gif.
This PR enables the Security AI assistant to be used globally - i.e. if
you are outside of the security solution (e.g. Discover), the Security
Assistant can still be opened.
Changes:
- A public module has been added to the elastic-assistant plugin
(previously it was a server-side-only plugin).
- The vast majority of the assistant (flyout and nav bar) has been moved
into the new elastic-assistantpublic plugin.
- Comment actions & message augmentations remain within the
security-solution.
- A new public plugin was created called elastic-assistant-shared state.
This plugin is used to share state between the elastic-assistant public
plugin and other plugins (e.g. security-solution).
- For example, the security solution registers comment actions in the
elastic-assistant-shared-state plugin. The elastic-assistant public
plugin then reads the comment actions from
elastic-assistant-shared-state and renders them in the assistant flyout.
### Considerations:
- Currently, the Security AI assistant is being displayed everywhere
except the observability solution (see implementation
[here](https://github.com/elastic/kibana/pull/223936/files#diff-5dd1ea91c2d5d242203cc58ee59ec283116e5e739ed82bae4e2cd78af322150c)).
This is only for testing while the PR is in review. We plan to add a
setting to the stack management that allows the user to configure where
they would like the assistant to be shown. This will be changed before
the PR is merged.
## How to test
Feel free to use the cloud and serverless deployments created by the CI
pipeline for testing. Credentials can be found on Buildkite.
### Verify that the Security AI assistant works as expected within the
security solution
Expected there to be no changes in how the security AI assistant works
within the Security Solution. Please do some exploratory testing to make
sure nothing has changed.
Start the branch locally and go to http://localhost:5601/app/security/
Things to test:
- Does the assistant open?
- Can I send an alert to the assistant from the alerts page?
- Does the assistant display code blocks correctly?
- Does the assistant display ESQL correctly (can I view the ESQL in the
timeline)?
- Do assistant messages have the correct comment actions? Do the comment
actions work?
- Are conversations displayed correctly?
- Do citations work?
- Does the assistant work in serverless? Does the assistant work as
expected in AI4SOC?
- Do quick prompts work?
- Can you select a system prompt for a new convo?
- Can you send alerts to the Security AI assistant?
- AI assistant in a space that has Security disabled.
- Does attack discovery work?
AI assistant open in Discover app:
<img width="1841" alt="image"
src="https://github.com/user-attachments/assets/0a13a100-d192-4fa4-b395-0951452e14c2"
/>
AI assistant in Security solution:
<img width="1841" alt="image"
src="https://github.com/user-attachments/assets/7ed38f37-79de-41a7-a80f-8b96147bfdf6"
/>
### Verify the Security AI assistant works in Discover (or anywhere
outside of the Security solution)?
Head over to http://localhost:5601/app/discover. Note that some
functionality is removed when using the AI assistant outside of
security:
- Only the "copy" comment action appears on messages.
- Code block augmentations (i.e. the button that opens ESQL inside of
the timeline) don't appear.
Things to test:
- Does the security AI assistant button appear in the nav bar?
- Can you open the security AI assistant?
- Are you able to send messages?
- Are conversations appearing as expected?
- Can you close the assistant?
- Do citations work?
- Can you switch to a different solution while the assistant is open?
Security AI assistant open in AI4SOC Discover:
<img width="1841" alt="image"
src="https://github.com/user-attachments/assets/36537b9b-e945-459e-ac13-43e9444e92b7"
/>
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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/src/platform/packages/shared/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
- [X] 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.
- [X] [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)
### 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>
## Summary
- Moved `search_navigation` to `plugins` root
- `search_navigation` being inside the search_solution folder was a
pre-cursor to the solutions/search migration. The introduction of the
solutions/search folder made the search_solution folder redundant,
therefore this migrates the search_navigation plugin up with all the
other search plugins.
- Moved the base classic nav items list to the search_navigation plugin.
The classic nav items are now a static list and can be servered from the
search_navigation plugin instead of being shared from
`enterprise_search`. This is mainly a devx improvement to allow all
search related navigation changes to eventually be maintained in the
search navigation plugin.
### 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/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
- [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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
* Address https://github.com/elastic/kibana/issues/217145 - Put in place
a check to ensure we're upgrading from Kibana 8.18.0 or newer.
* Address https://github.com/elastic/kibana/issues/220521 - New attempt
at removing the `switchToModelVersionAt` property, inspired on
https://github.com/elastic/kibana/pull/219029.
The previous attempt caused a regression: index meta information started
storing _modelVersions_ that were older than the previously stored ones,
which were defaulting to 10.0.0 for SO types that did NOT define
`modelVersions`.
This was due to the removal of the applyTypeDefaults, which was ensuring
all SOs had the `switchToModelVersionAt` property set.
This flag was then used by
`src/core/packages/saved-objects/base-server-internal/src/model_version/version_map.ts`
to determine whether to use `modelVersions` or the legacy `migrations`
property in order to determine the latest model version for a given
type.
When removing the `switchToModelVersionAt` flag (and its default
backfill), the logic started defaulting to the latest `migrations`
version for those SO types that were not defining any `modelVersion`,
resulting in older versions that those stored in the SO indices. This
caused incident https://elasticco.atlassian.net/browse/INC-3818.
This regression has been shipped in 9.0.0 (the PR was
[backported](https://github.com/elastic/kibana/pull/219329)), so in top
of the cleanup, we now need to address
https://github.com/elastic/kibana/issues/220521 to ensure a smooth
transition _OnPrem => Serverless_.
---------
Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR applies **lossless compression** to all SVG and JPG/PNG assets
across Kibana using:
- [`svgo`](https://github.com/svg/svgo) — for optimizing SVGs
- [`image-optimize`](https://www.npmjs.com/package/image-optimize) — for
JPG/PNG compression
‼️**Please scroll to ''Unknown metric groups" accordion to see what's
the gain for your code.**
<img width="542" alt="Screenshot 2025-06-18 at 13 24 20"
src="https://github.com/user-attachments/assets/191afb28-44fc-4551-9026-756a8385c66a"
/>
The goal is to reduce asset size and improve load performance without
compromising visual quality.
This PR achieves a **23 MB** reduction in asset size across all images
bundled in Kibana’s running code—meaning these compressed images
directly impact what ships in Kibana.
Some assets get bundled into chunks due to our bundling strategy but
might not actually be requested at runtime.
Additionally, I ran the same optimization script on the docs assets as a
harmless extra step, but those savings aren’t included in the 23 MB
total.
---
## Why
While working on Emotion rewrites, I noticed some SVGs seemed
unnecessarily heavy. That led to a broader investigation into our image
assets, and it turns out we’re not consistently optimizing them during
development or build.
---
## Notes
- Visual fidelity of optimized assets has been manually verified — no
visible differences
- The optimization is **lossless**, meaning no quality degradation
- Some assets (like large background images) could benefit further from
**lossy compression**
---
## Follow-ups / Ideas
1. **Automate compression in the dev/build pipeline**
- e.g. add `svgo` as a pre-commit or CI step for SVGs
2. **Improve CI reporting**
- Currently, bundle size diffs for images are hidden under "Unknown
metric groups" in the GitHub CI comment. We may want to make these more
visible.
-
3. **Audit large assets manually** — apply lossy compression where
appropriate
4. **Avoid redundant image loading**
- e.g. background images on the login page are loaded again on the space
selector page since they’re bundled twice. I’m working on a separate PR
to address that.
## Snippets I used to apply the compression
```
# Find SVG files
find . -type f -iname "*.svg" \
-not -path "*/node_modules/*" \
-not -path "*/functional/*" > svg-files.txt
# Compress SVGs
while IFS= read -r file; do
svgo "$file"
done < svg-files.txt
```
This snippet has been used for png and jpg, but the example below is for
png:
```
# Find PNG files
find . -type f -iname "*.png \
-not -path "*/node_modules/*" \
-not -path "*/functional/*" > png-files.txt
# Compress PNGs
while IFS= read -r file; do
image-optimize -f jpg "$file"
done < png-files.txt
```
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 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>
## 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>
## 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>
## 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
## Summary
Part of https://github.com/elastic/kibana/issues/201807
**Strategy**:
This PR assumes that `switchToModelVersionAt` has done it’s job and all
SO type owners now use `modelVersions` instead of `migrations`.
It takes the approach of trusting that this is fine™
**Changes in this PR:**
- `switchToModelVersionAt` removed from all registered saved objects, so
their mapping hash had to be updated.
- Implements `globalSwitchToModelVersionAt` directly in `version_map`
- Updates logic to prioritize `modelVersions` over `migrations` in
`getLatestMappingsModelVersion`, that previously relied on
`switchToModelVersionAt` being set
- Updates unit tests to match the refactored logic
- Updates snapshots
- Adapts SO types registered in the **cases**, **SLO** and **encrypted
saved objects** plugins.
- Updates docs
**Risks**:
- Plugin developers disregard the deprecated status of `migrations` and
introduce new versions, which will not be BWC. Saved object type hash
changes will notify the core team for a code owner review. The core team
needs to investigate the related changes and provide feedback.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
- [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: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**!!MAJORITY OF THE CHANGED FILES ARE MOVED OR COPIED!!**
### Vision
According to the product vision we will build a new simple UI/UX in the
future https://github.com/elastic/security-team/issues/11790
This PR is a first iteration on enabling Content Connectors Management
UI in Serverless Kibana Stack Management.
Elastic Managed content connectors will be available only for Security
and Observability projects.
### Current PR scope
1. Used initial search_connectors plugin and renamed it to
content_connectors + moved from `x-pack/solutions/search` to
`x-pack/platform/plugins/shared`
2. Copy relevant connectors UI and routes from enterprise_search plugin.
3. Introduce the new Stack Management card/navigation option under the
Data section.
4. Enabled this plugin only in Serverless for Security and Observability
projects.
5. For making PR smaller Pipelines tab was not moved. And according to
Search team vision this functionality should be dropped anyway soon.
6. Extended fleet package logic to include elastic_connectors for
security and o11y serverless projects
7. Added back `search:agentless-connectors-manager` task
In Stack Management navigation:
<img width="2062" alt="Screenshot 2025-04-15 at 3 51 43 PM"
src="https://github.com/user-attachments/assets/5c93ba01-9a6a-4eac-a21d-1370f03b8f35"
/>
Stack Management cards:
<img width="2081" alt="Screenshot 2025-04-10 at 8 41 43 PM"
src="https://github.com/user-attachments/assets/3def1c12-561b-4a84-8241-4dd61cd9313d"
/>
Create Elastic Managed Connector UI (on Agentless):
<img width="1822" alt="Screenshot 2025-04-15 at 3 55 29 PM"
src="https://github.com/user-attachments/assets/6e9fea48-85e7-43df-919d-0e5492d0e704"
/>
Create Self Managed Connector UI:
<img width="2064" alt="Screenshot 2025-04-15 at 3 55 49 PM"
src="https://github.com/user-attachments/assets/d5051898-c8fa-4e41-b9ea-b41d4ed4a0d5"
/>
### Next steps
- [ ] Remove duplicated code between content_connectors,
enterprise_search and serverless_search
- [ ] Extract [common server
libs](https://github.com/elastic/kibana/tree/main/x-pack/solutions/search/plugins/enterprise_search/server/lib)
to the shared package `kbn-search-connectors`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Artem Shelkovnikov <artem.shelkovnikov@elastic.co>
Co-authored-by: Artem Shelkovnikov <lavatroublebubble@gmail.com>
Co-authored-by: Kyle Pollich <kyle.pollich@elastic.co>
## Summary
Pre-requisite for https://github.com/elastic/kibana/pull/216088, as the
`AI Assistant Management` configuration settings should be available for
Search too.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes image paths to work with docs-assembler.
Notes for the reviewer:
* I was not able to get images in reference, extend, or release-notes to
work using the `:::{image}` syntax because it seems to resolve
differently than the Markdown `![]()` syntax. We should address this in
docs-builder, but in order to get images working as soon as possible,
I've used Markdown syntax and left us a `TO DO` in a code comment to add
back the `screenshot` class where applicable.
* Can you please add the appropriate labels needed for backporting?
## Summary
Removes unused code from the Investigate and Investigate app plugin.
Removes all references to those plugins in storybook, i18n, types, etc.
Removes codeowner requirements for those plugins
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/190661
This PR allows tasks to be ran scoped as the current user. It
accomplishes this by creating an API when the user schedules this task.
It will then persist the API key in the task instance which allows the
task handler to have access to the user's privileges.
To test:
1. Run `yarn start --run-examples`
2. Navigate to
`http://localhost:5601/app/triggersActionsUiExample/task_manager_with_api_key`
3. Click on `Schedule Task 1 and 2`, this will schedule a mock test that
is defined in
`x-pack/platform/plugins/shared/alerting/server/plugin.ts`, which prints
out the task instance and the scoped clients.
4. Click on `Remove` to cancel the task, which then cleans up and
invalidates the API keys.
5. Reschedule the 2 tasks and click on `Remove All Tasks` which will
bulk remove tasks and invalidate API keys.
Limitation of this approach:
- Because we depend on a request, this would mean every schedule that is
tied to a user needs to be triggered using a request. (Unless we have a
way of generating an API key without using the request).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
~**DO NOT MERGE:** depends on
https://github.com/elastic/kibana/issues/213468~
This PR reintegrates the work from the `workchat_m1` branch into `main`:
- introduces a 4th solution type, `chat`, that will be used for the
*WorkChat* project type.
- edit things in various platform code to introduce/handle that new
project type
- add plugins and packages for the workchat app.
### To AppEx reviewers:
File change count is scary, but you can safely ignore anything from
`xpack/solutions/chat` (given it's solution code), and focus on your
owned changes, which are way more reasonable
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Joe McElroy <joseph.mcelroy@elastic.co>
Co-authored-by: Rodney Norris <rodney.norris@elastic.co>
Co-authored-by: Jedr Blaszyk <jedrazb@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Meghan Murphy <meghan.murphy@elastic.co>
## Summary
A [recent PR](https://github.com/elastic/kibana/pull/212558/files) (3
weeks ago) migrated docs under `/docs` folder, from `.asciidoc` to
`.md`.
Unfortunately, some of these docs (well, at least one) were generated
automatically using a script:
`node scripts/build_plugin_list_docs.js` was updating the
`docs/developer/plugin-list.asciidoc`
As a result of the migration:
The CI pipeline step fails, and the list of plugins is no longer
updated.
Besides:
* The https://www.elastic.co/guide/en/kibana/current/plugin-list.html is
currently broken.
* This page is (or should be) built from
https://github.com/elastic/kibana/blob/main/docs/extend/plugin-list.md,
which is also broken.
They are broken cause some plugins' descriptions use the pipe `|`
character, which breaks the Markdown layout.
This PR updates the logic that generates the plugin-list, switching from
`.asciidoc` to `.md`, and escaping `\n` and `|` characters to allow for
better descriptions.
In https://github.com/elastic/docs-builder/pull/699, we added the
ability to pass arguments to code blocks. In this repo, there are a few
code blocks that list two languages (`typescript jsx`). The docs-builder
interprets the second language `jsx` as an argument, but `jsx` is not a
valid argument so it throws an error. This should fix the `docs-build`
check.
cc @elastic/docs-engineering
Migrate docs from AsciiDoc to Markdown. The preview can be built after
#212557 is merged.
@florent-leborgne please tag reviewers, add the appropriate label(s),
and take this out of draft when you're ready.
Note: More files are deleted than added here because the content from
some files was moved to
[elastic/docs-content](https://github.com/elastic/docs-content).
**What has moved to
[elastic/docs-content](https://github.com/elastic/docs-content)?**
Public-facing narrative and conceptual docs have moved. Most can now be
found under the following directories in the new docs:
- explore-analyze: Discover, Dashboards, Visualizations, Reporting,
Alerting, dev tools...
- deploy-manage: Stack management (Spaces, user management, remote
clusters...)
- troubleshooting: .... troubleshooting pages
**What is staying in the Kibana repo?**
- Reference content (= anything that is or could be auto-generated):
Settings, syntax references
- Release notes
- Developer guide
---------
Co-authored-by: Florent Le Borgne <florent.leborgne@elastic.co>
