## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR is mostly about moving tests from
x-pack/test/cases_api_integration and updating related imports
Before:
```
x-pack/test/
| - cases_api_integration/
```
After:
```
x-pack/platform/test/
| - cases_api_integration/
x-pack/solutions/security/test/
| - cases_api_integration/
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Adds a recommended query for the `CATEGORIZE` function in ES|QL.
Adds keyword highlighting for the patterns and the ability to open a new
Discover tab to filter for docs which match the selected pattern.
https://github.com/user-attachments/assets/9ed8c5b0-7e92-4cc8-88dd-cb7749b5ffd3
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
## 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
Part of https://github.com/elastic/kibana-team/issues/1503
This PR adds `kbn/cypress-test-helper` as platform shared package to
replace invalid imports from private `security-solution` plugin in
platform shared plugin `osquery`.
The reason is that we are **currently blocked with x-pack relocation due
to circular dependency**, e.g. in
https://github.com/elastic/kibana/pull/223897
```
info starting [tsc] > node_modules/typescript/bin/tsc -b tsconfig.refs.json --pretty
--
| 2025-06-13 13:17:30 UTC | proc [tsc] error TS6202: Project references may not form a circular graph. Cycle detected: /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/tsconfig.refs.json
| 2025-06-13 13:17:30 UTC | proc [tsc] /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/x-pack/platform/plugins/shared/osquery/cypress/tsconfig.type_check.json
| 2025-06-13 13:17:30 UTC | proc [tsc] /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/x-pack/test_serverless/tsconfig.type_check.json
| 2025-06-13 13:17:30 UTC | proc [tsc] /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/x-pack/solutions/security/test/tsconfig.type_check.json
| 2025-06-13 13:17:30 UTC | proc [tsc] /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/x-pack/test/security_solution_endpoint/tsconfig.type_check.json
```
**Important:**
This PR focuses only on replacing test helpers imports from
`@kbn/security-solution-plugin` and `@kbn/test-suites-xpack` in
`osquery` plugin, no code cleanup and updates in other plugins / test
packages.
We expect code owners to update other imports / refactor package to
avoid code duplication
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@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
This PR introduces a few structural and cleanup improvements:
1. Moves core Emotion CSS helpers (`useMemoizedStyles` renamed as
`useMemoCss`, `kbnFullBodyHeightCss`, `kbnFullScreenBgCss`) from
`core/public` to a new package: `@kbn/css-utils`.
2. Removes a significant portion of legacy SCSS from the core plugin.
3. Replaces scss mixin with emotion `kbnFullScreenBgCss` across Kibana
(we have scss and emotion version, but emotion version wasn't widely
used yet).
4. As a result of (3), some plugin tests were migrated to React Testing
Library. This was necessary because Emotion-generated snapshots in
Enzyme were difficult to read and maintain when moving to emotion.
### Considerations
I initially tried to add the package to the [shared-deps
bundle](8e15517ddd),
but couldn’t get the SVG imports for `kbnFullScreenBgCss` to work
correctly in that setup.
As a workaround, I opted to import the helpers directly from their
source files.
An alternative approach could be to convert the used SVGs into React
components and use those within the shared package. Or explore something
like a static package and try to somehow wire in that in the webpack
internal compilers, but it doesn't seem to be worth the effort at the
moment.
### 💡 Motivation
- These utils don’t need to live in Core and are now decoupled to
improve performance and flexibility.
- Importing from `core/public` (even just for a small hook) was adding
noticeable overhead to test runs:
- ~1–2s delay on first Jest execution
- ~200ms added on subsequent runs
- Occasional CI timeouts due to deep import graph
### 👥 Ownership
I assigned this package to sharedux team. Thank you!
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/search-team/issues/10121
Add a base set of retrieval oriented tools, and expose them to the
default agent.
## Tools
**Warning: names are still TBD**
We're starting to see two different "layers" of tool appear: "simple"
tools, which are doing a simple programmatic (understand: no LLM) task,
and "smart" tools, which are more like workflows, with some of the steps
relying on a LLM.
This PR introduces the following tools:
### Simple tools
Simple tools (name TBD) are "programmatic" tools not relying on an LLM
for their execution.
This PR introduces this base set of tools:
- `get_document_by_id`: resolve a full document based on its id/index.
- `list_indices`: list the indices the current user has access to.
- `get_index_mappings`: retrieve the full mappings based for a given
index.
- `execute_esql`: executes a provided ES|QL query
### Smart tools
Smart tools can have multiple internal steps (even if it remains an
implementation detail), and are using LLM calls for some, or all, of
them.
*Note: there are huge potential areas of improvement in the current
implementation of all those smart tools. One of the intent of this work
is precisely to identify such areas of improvement*
#### `index_explorer`
Based on a natural language query, returns a list of indices that should
be searched, and their corresponding mappings.
<img width="984" alt="Screenshot 2025-06-17 at 16 44 32"
src="https://github.com/user-attachments/assets/edff3964-31e3-40ea-a761-adf7c45fcb17"
/>
#### `generate_esql`
Based on a natural language query, generates an ES|QL query.
- use the `nl-2-esql` task under the hood
- optional use `index-explorer` if `index` is not specified.
<img width="891" alt="Screenshot 2025-06-17 at 16 51 56"
src="https://github.com/user-attachments/assets/ce141d6b-dd4f-4eb9-ab32-823b81bc810b"
/>
#### `relevance_search`
Perform a "full-text search" based on given term and returns the most
relevant highlights.
<img width="1071" alt="Screenshot 2025-06-17 at 16 59 49"
src="https://github.com/user-attachments/assets/1f873e70-e277-424d-93e4-24b269a554e5"
/>
#### `natural_language_search`
Retrieve data based on a natural language query.
Converts a natural language query to an ES|QL one then executes it,
useing `generate_esql` and `execute_esql` under the hood.
<img width="768" alt="Screenshot 2025-06-18 at 08 31 52"
src="https://github.com/user-attachments/assets/cb319831-17ed-4ad7-9e1f-2fe90c2472fa"
/>
## Researcher assistant
The second part of this PR is implementing a researcher agent for deep
research tasks.
The researcher assistant is following a very classic
"act->process->reflect" cycle.
<img width="960" alt="Screenshot 2025-06-18 at 09 16 17"
src="https://github.com/user-attachments/assets/c24be323-ecf2-4c43-88fb-eaf874b18afc"
/>
The implementation of the cycle is currently as follow:
**1. Act**
Given a research topic, the research history and a list of tools, select
the tool best suited to search for this topic, and call it.
The tools exposed to the agent in this phase are:
- `index_explorer`
- `relevance_search`
- `nl_search`
*Note: later the whole `act` step could evolve to instead call sub
search agent with planning and multi-step execution.*
**2. Process**
Process the results from the latest `act` phase and create a
corresponding entry in the search log.
At the moment, we're simply storing the whole tool call + results to the
search log in a LLM-friendly format.
**3. Reflect**
Based on the main research query and the search log, identify where the
information collected are enough to answer the question. If not,
identify follow-up questions or sub-problems that it would be useful to
solve to gather more information
## What is out of scope of the current PR
- Figuring out which set of tools should be exposed by default to the
main agent (right now, all the tools listed in this PR are)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This is largely based of @clintandrewhall's work that he extracted from
the new workspace layout poc. These components are a decent starting
point for [new grid layout
](https://github.com/elastic/kibana-team/issues/1581) and I
[validated](https://github.com/elastic/kibana/pull/223021) that the
layout mostly works for Kibana (fixing a couple of edge cases)
I believe the components are ready to be merged into the main branch to
make future reviews easier:
Bootstraps a new `@kbn/core-chrome-layout-components` package to provide
composable React primitives for Kibana’s Chrome layout, including region
components, a debug overlay, Storybook stories, and initial docs.
- Adds layout region components (Banner, Header, Navigation, Sidebar,
Panels, Application, Footer) and a debug overlay with Emotion styling.
- Provides a README with usage examples (Storybook-driven) and API
documentation.
`yarn storybook sharedux`
---------
Co-authored-by: Clint Andrew Hall <clint@clintandrewhall.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR is mostly about moving tests from
x-pack/test/alerting_api_integration
Before:
```
x-pack/test/alerting_api_integration
| - basic/
| - common/
| - observability/
| - packages/
| - security_and_spaces/
| - spaces_only/
| - spaces_only_legacy/
```
After:
```
x-pack/platform/test/alerting_api_integration
| - basic/
| - common/
| - packages/
| - security_and_spaces/
| - spaces_only/
| - spaces_only_legacy/
x-pack/solutions/observability/test/alerting_api_integration
| - observability/
x-pack/solutions/security/test/alerting_api_integration
| - security_and_spaces/group1/
| - security_and_spaces/group2/
```
Details:
- few tests in original `backfill` dir use helper function relying on
import from `@kbn/security-solution-plugin`, both tests and helpers were
relocated to `x-pack/solutions/security/test` dir.
- `observability` dir and its tests were relocated directly to
`x-pack/solutions/observability/test` dir.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Moves the recurring schedule (rrule) form from the Maintenance Windows
form to a dedicated package.
## Implementation details
~~Because of the tight time constraints we have for this epic, I tried
to change the recurring schedule form as little as possible, keeping the
existing form-lib-based implementation and adding an intermediate layer
to embed the editing UI in larger forms (i.e. MW form). While this is
not particularly elegant, it allows us to build on top of an existing,
tested codebase and to leverage form-lib's validation and state
management capabilities.~~
~~In the context of the MW form, the recurring schedule editor is
treated as a single field. Value and error updates are synced through
form-lib's field hook API:~~
acd6a4823e/x-pack/platform/plugins/shared/alerting/public/pages/maintenance_windows/components/recurring_schedule_field.tsx (L21-L34)
~~Errors are handled internally by the schedule editor, but must still
be surfaced up to the parent form in order to have a consistent validity
state (otherwise submits are not prevented even if errors are shown in
the UI).~~
The recurring schedule form schema and form fields are exported to be
reused in larger form-lib forms.
## References
Closes#219454
### 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>
Add a `prompt` API to the Inference plugin. This API allow consumers to
create model-specific prompts without having to implement the logic of
fetching the connector and selecting the right prompt.
Some other changes in this PR:
- the `InferenceClient` was moved to `@kbn/inference-common` to allow
for client-side usage
- Tracing for prompts was added
- A bug with the Vertex adapter and tool call errors was fixed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Moves the core file upload classes to a package called
`@kbn/file-upload`
Moves a lot of shared and duplicated constants to the package
`@kbn/file-upload-common`
Adds a new context called `FileUploadContext` and related hook
`useFileUploadContext` to manage all aspects of the file upload process.
Updates the file upload lite flyout used by the Search solution to use
this new context.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
Closes https://github.com/elastic/observability-dev/issues/4490
We need to introduce a tier concept in Kibana to offer tiered versions
of our Observability solution.
Some time ago, the security team did something similar to introduce
tiered product lines, and this work lays the foundation for a Kibana
shared solution that can work with product tiers.
This PoC introduces a new core `PricingService` to manage feature
availability based on subscription tiers in serverless deployments. The
implementation enables:
- Tier-aware feature registration.
- Dynamic configuration loading based on
`serverless.<project-type>.<tier>.yml` files.
- Client/server APIs for feature checks based on available tier
(`isFeatureAvailable()`)
- Backwards compatibility with existing project types (Search,
Observability, Security, Chat)
## 🚶 Architecture walkthrough
### Configuration
To have a mechanism that allows for performing changes at the
configuration level, the `PricingService` loads and validates a strict
configuration of product tiers.
The available configuration is defined as follows:
```yml
# serverless.oblt.yml (default config)
pricing.tiers.enabled: true
pricing.tiers.products:
- name: observability
tier: complete
# serverless.oblt.complete.yml
xpack.infra.enabled: true
xpack.slo.enabled: true
xpack.features.overrides:
// Etc...
# serverless.oblt.essentials.yml
xpack.infra.enabled: false
xpack.slo.enabled: false
// Etc...
# Optionally, security solution could set their product tiers from their configuration files, as they are already supported by the core pricing service
# serverless.security.yml
pricing.tiers.enabled: true
pricing.tiers.products:
- name: security
tier: complete
- name: endpoint
tier: complete
- name: cloud
tier: complete
```
The Control Plane team will update how the kibana-controller inject the
configuration in the `kibana.yml` file to reflect the values set during
the project creation.
It will also auto-load any optional
`serverless.<project-type>.<tier>.yml` matching the config definition
when tiers are enabled.
The configuration is strictly validated against typed products. It might
be very opinionated to store this validation in a core package, but it
ensures strong typing across the codebase to register product features
and ensure a fast-failing check in case the product tiers do not exist.
### Pricing service
As far as the configuration-based approach is great to disable whole
plugins and override configs, it doesn't cover all the scenarios where a
specific tier wants to limit minor parts of a plugin feature (e.g., for
o11y limited onboarding, we cannot disable the whole plugin).
To cover these cases, the `PricingService` exposes a mechanism to
register features associated with specific tiers.
This is unbound from the `KibanaFeatureRegistry` mechanism, and we could
consider extending its behaviour in the future as needed. Once product
features are registered, the core start contract exposes a simple client
to detect when a feature is available.
<img width="1453" alt="Screenshot 2025-05-23 at 12 35 11"
src="https://github.com/user-attachments/assets/05267c00-afe0-49c6-b518-b1ce8f4a0546"
/>
## ✏️ Usage
To launch Kibana with a specific product tier (e.g. observability
`essentials`, mostly limiting to logs features), update the
`pricing.tiers.products` in the serverless project configuration file:
```yml
# serverless.oblt.yml
pricing.tiers.enabled: true
pricing.tiers.products:
- name: observability
tier: essentials
```
The above will run a Kibana serverless project in this specific tier and
will load the configuration defined in `serverless.oblt.essentials.yml`,
which currently disables a couple of plugins.
Given this context, let's take a limited o11y onboarding when the
subscription tier is `essentials`:
```ts
// x-pack/solutions/observability/plugins/observability_onboarding/server/plugin.ts
export class ObservabilityOnboardingPlugin {
public setup(core: CoreSetup) {
// ...
// Register a feature available only on the complete tier
core.pricing.registerProductFeatures([
{
id: 'observability-complete-onboarding',
products: [{ name: 'observability', tier: 'complete' }],
},
]);
// ...
}
}
// x-pack/solutions/observability/plugins/observability_onboarding/public/application/onboarding_flow_form/onboarding_flow_form.tsx
const { core } = useKibana();
const isCompleteOnboardingAvailable = core.pricing.tiers.isFeatureAvailable('observability-complete-onboarding');
if (isCompleteOnboardingAvailable) {
return <CompleteOnboarding />;
} else {
return <EssentialsOnboarding />;
}
```
The results of the above changes will look as follows once Kibana is
running:
| Complete tier | Essentials tier |
|--------|--------|
| <img width="2998" alt="Screenshot 2025-05-23 at 13 51 14"
src="https://github.com/user-attachments/assets/bcf7c791-4623-42e4-91ce-0622d981e7e7"
/> | <img width="2996" alt="Screenshot 2025-05-23 at 13 53 36"
src="https://github.com/user-attachments/assets/429c82eb-761c-4aa1-b13d-81ac95301e60"
/> |
The tiers client is also available server-side through the
`getStartServices()` function, such that ad-hoc activity/registrations
can be performed.
## 👣 Next Steps
- [x] Implement pending core tests
- [x] Document API usage in README
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR is mostly about moving tests from x-pack/test to platform and
solutions dirs
Before:
```
x-pack/test/api_integration
| - apis/metrics_ui/
| - apis/ml/
| - apis/entity_manager/
| - apis/search_playground/
```
After:
```
x-pack/platform/test/
| - apis/entity_manager/
| - apis/ml/
x-pack/solutions/observability/test/
| - apis/metrics_ui/
x-pack/solutions/search/test/
| - apis/search_playground/
```
New test package was created under `x-pack/solutions/search/test` for
Search solution tests.
---------
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 creates a separate package with `getSpaceIdFromPath` exported to
avoid creating a circular dependency in
https://github.com/elastic/kibana/pull/220138
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR is mostly about moving tests from `x-pack/test` to
`x-pack/platform/test`
Before:
```
x-pack/test/
| - api_integration/apis/management/
| - api_integration/apis/monitoring/
| - api_integration/apis/osquery/
| - automatic_import_api_integration
| - monitoring_api_integration/
| - saved_object_api_integration/
```
After:
```
x-pack/platform/test/
| - api_integration/apis/management/
| - api_integration/apis/monitoring/
| - api_integration/apis/osquery/
| - automatic_import_api_integration
| - monitoring_api_integration/
| - saved_object_api_integration/
```
Additional:
- `x-pack/test/api_integration/apis/osquery/config.ts` was move to
platform stateful manifest to match `osquery` plugin (shared, platform)
- `automatic_import_api_integration` config files were moved to platform
stateful manifest to match `automatic_import` plugin (shared, platform)
- `x-pack/test/common/lib/test_data_loader.ts` is required by SO api
tests and was copied to `x-pack/platform/test/common`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Instrument the inference chatComplete API with OpenTelemetry, and export
helper functions to create spans w/ the right semconv attributes.
Additionally, optionally export to Langfuse or Phoenix.
## Centralizes OpenTelemetry setup
As this is the first instance of OpenTelemetry based _tracing_ (we
already have metrics in the MonitoringCollection plugin), some
bootstrapping code is necessary to centrally configure OpenTelemetry. To
this end, I've added the following config settings:
- `telemetry.tracing.enabled`: whether OpenTelemetry tracing is enabled
(defaults to undefined, if undefined, falls back to `telemetry.enabled`)
- `telemetry.tracing.sample_rate` (defaults to 1)
The naming of these configuration settings is mostly in-line with [the
Elasticsearch tracing
settings](https://github.com/elastic/elasticsearch/blob/main/TRACING.md).
The following packages (containing bootstrapping logic, utility
functions, types and config schemas) were added:
- `@kbn/telemetry`
- `@kbn/telemetry-config`
- `@kbn/tracing`
The OpenTelemetry bootstrapping depends on @kbn/apm-config-loader, as it
has the same constraints - it needs to run before any other code, and it
needs to read the raw config.
Additionally, a root `telemetry` logger was added that captures
OpenTelemetry logs.
Note that there is no default exporter for spans, which means that
although spans are being recorded, they do not get exported.
## Instrument chatComplete calls
Calls to `chatComplete` now create OpenTelemetry spans, roughly
following semantic conventions (which for GenAI are very much in flux).
Some helper functions were added to create other inference spans. These
helper functions use baggage to determine whether the created inference
span is the "root" of an inference trace. This allows us to export these
spans as if it were root spans - something that is needed to be able to
easily visualize these in other tools.
Leveraging these inference spans, two exporters are added. One for
[Phoenix](https://github.com/Arize-ai/phoenix) and one for
[Langfuse](https://github.com/langfuse/langfuse/tree/main): two
open-source LLM Observability suites. This allows engineers that use the
Inference plugin to be able to inspect and improve their LLM-based
workflows with much less effort.
For both Phoenix and Langfuse, two service scripts were added. Run `node
scripts/phoenix` or `node scripts/langfuse` to get started. Both scripts
work with zero-config - they will log generated Kibana config to stdout.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/214448
As part of the Traces in Discover feature we want to add latency
duration chart to the already existing duration section.
### Details
- Created `latencyOverallSpanDistributionRoute` based on
`latencyOverallTransactionDistributionRoute` to gather the data needed
for rendering the span chart.
- We may reconsider whether this should remain in APM or be moved to a
shared package for better typing, easier exposure, and easier
maintenance. There's an
[issue](https://github.com/elastic/kibana/issues/216959) to address
this.
- Split `TraceDocumentOverview` into `TransactionDocumentOverview` and
`SpanDocumentOverview`, and also split `getTraceDocumentOverview` into
`getTransactionDocumentOverview` and `getSpanDocumentOverview`.
- Created `DurationDistributionChart` in `kbn-apm-ui-shared` based on
the `DurationDistributionChart` in APM.
- Keep in mind that it's an exact clone of the component and its
dependencies, excepting a couple of booleans I added as props, so I
don't expect any of it to be reviewed as part of this PR
- We'll be removing the APM version in favor of this one as part of this
[issue](https://github.com/elastic/kibana/issues/211781), so it only
exists in one place.
- Removed the telemetry TODOs since the issue was closed, and no
additional work is needed for tracking click links.
Both spans and transactions will now have the latency duration chart:
|Details||
|-|-|
|Transaction||
|Span||
|Loading||
|Dark mode||
## How to test
- Enable the discover profiles by adding this to the` kibana.yml `file:
```
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
- Make sure your space has Observability as Solution View.
- Open Discover and select or create a data view that includes any APM
traces index (`traces-*`), or query them using ES|QL.
- Apply a filter for `data_stream.type:"traces"` to ensure only trace
documents are retrieved.
- Open the flyout.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Carlos Crespo <crespocarlos@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>
Expose LockManager as package to make it easier to consume from other
plugins
cc @nchaulet
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Viduni Wickramarachchi <viduni.ushanka@gmail.com>
## Summary
This PR creates an `upgrade-assistant` package, moves a component to the
package, and creates a storybook story for it. Run `yarn storybook
upgrade_assistant` to see it.
The intention is to make it easier to work on upgrade assistant
components in isolation from kibana and the state necessary to display
them.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elena Stoeva <59341489+ElenaStoeva@users.noreply.github.com>
Part of https://github.com/elastic/kibana-team/issues/1503
This PR creates new "test-helper" package
`@kbn/test-suites-xpack-platform` to store Platform functional tests.
It copies few simple FTR services, base config file and context provider
to the new structure.
First chunk of tests is moved as well:
x-pack/**test**/api_integration/apis =>
x-pack/**platform/test**/api_integration/apis
<img width="514" alt="image"
src="https://github.com/user-attachments/assets/ddd84d28-cba4-41fe-bdeb-32a14b4e3f17"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
close https://github.com/elastic/kibana/issues/216459
follow-up to https://github.com/elastic/kibana/pull/216489
Since we're migrating to Emotion from SCSS/styled-components, this PR
globally aligns the Jest setup by adding '@emotion/jest' matchers.
However, the matchers conflict with the styled-components Jest matchers,
so I had to disable them globally and reapply them in the tests where
they were used (either the matchers or styled components snapshot
serializer) . Tracking issue to clean this up
https://github.com/elastic/kibana/issues/219037 when migrated to Emotion
## Summary
Allows one to export and import content packs in archive format. The
format follows the integration content package's format so it becomes
possible to import existing integration packages.
Content packs only support dashboard assets at the moment.
A pattern replacement logic has been implemented for dashboards and
referenced data views:
- at export time, any pattern matching the source stream will be
replaced with a placeholder. Other patterns will remain as-is unless
user explicitly ask to replace them
- at import time, the placeholders are replaced with the target stream
pattern
For example, if a dashboard is first exported from stream `logs.nodejs`
and reads data from patterns `logs.nodejs` and `logs.nodejs.prod`, the
patterns will be updated to `logs.ruby` and `logs.ruby.prod` when
imported into `logs.ruby` stream.
The relevant UI components are hidden behind a feature flag, set the
following in `kibana.dev.yml` to enable them:
`feature_flags.overrides.featureFlagsStreams.contentPackUIEnabled: true`
https://github.com/user-attachments/assets/9fb07daf-9fb9-4c62-9f5b-387e1833eaf0
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: tommyers-elastic <106530686+tommyers-elastic@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
Implements the alerts filters form that will be used to pre-filter the
alerts table embeddable.
<img width="1004" alt="image"
src="https://github.com/user-attachments/assets/b51ce051-40d2-42d0-a9c1-0fba3fd919af"
/>
> [!NOTE]
> I'm using the terminology "form" to distinguish this from the alert
filter _controls_ or other type of more KQL-bar-like filters. Other
alternatives that came to mind were `alerts-boolean-filters-...` or
`alerts-filters-builder`.
<details>
<summary>
## Implementation details
</summary>
### Filters expression state
I opted for a tree state representation of the form's boolean expression
to accommodate potential future requirements such as more complex
boolean expressions (negation, parenthesized subexpressions to manually
control operators precedence):
```ts
{
operator: 'or',
operands: [
{
operator: 'or',
operands: [
{ type: 'ruleTags', value: ['tag-1'] },
{ type: 'ruleTags', value: ['tag-2'] },
{
operator: 'and',
operands: [{ type: 'ruleTypes', value: ['type-1'] }, { type: 'ruleTypes', value: ['type-2'] }],
},
],
},
{ type: 'ruleTags', value: ['tag-3'] },
],
}
```
This state is saved in the embeddable panel state and represents the
editor form. The embeddable alerts table wrapper component will then
transform this to an actual ES query.
To simplify interactions inside the form, an intermediate equivalent
flattened state is used:
```ts
[
{ filter: { type: 'ruleTags', value: ['tag-1'] } },
{ operator: 'or' },
{ filter: { type: 'ruleTags', value: ['tag-2'] } },
{ operator: 'or' },
{ filter: { type: 'ruleTypes', value: ['type-1'] }},
{ operator: 'and' },
{ filter: { type: 'ruleTypes', value: ['type-2'] } },
{ operator: 'or' },
{ filter: { type: 'ruleTags', value: ['tag-3'] } },
]
```
### Filters model
Each filter is described by an `AlertsFilterMetadata<T>` object, where
`T` is the type of the filter value:
```tsx
export const filterMetadata: AlertsFilterMetadata<string[]> = {
id: 'ruleTags',
displayName: RULE_TAGS_FILTER_LABEL,
component: AlertsFilterByRuleTags,
// Filter-specific empty check
isEmpty: (value?: string[]) => !value?.length,
// Conversion to ES query DSL
toEsQuery: (value: string[]) => {
return {
terms: {
[ALERT_RULE_TAGS]: value,
},
};
},
};
```
</details>
## Verification steps
1. Run Kibana with examples (`yarn start --run-examples`)
2. Create rules in different solutions with tags
3. Navigate to `/app/triggersActionsUiExample/alerts_filters_form`
4. Check that the solution selector options are coherent with the rule
types the user can access
5. Select a solution
6. Build filters expressions, checking that the rule tags and rule types
are coherent with the solution selection and the rules created
previously
7. Repeat steps 3-6 with different roles:
7.1. having access to rule types from just one solution (in this case
the solution selector shouldn't appear at all),
7.2. having access just to Observability and Stack but not Security (in
this case the solution selector shouldn't appear at all),
8. Repeat steps 3-6 in the three serverless project types:
```shell
$ yarn es serverless —ssl --projectType <es|oblt|security>
$ yarn serverless-<es|oblt|security> --ssl --run-examples
```
(If the authentication fails when switching between project types, use a
clean session)
8.1. ES project types should have access only to Stack rules (no
selector)
8.2. Observability project types should have access only to
Observability and Stack rules (no selector)
8.3. Security project types should have access only to Security and
Stack rules (selector shows Stack instead of Observability)
## References
Depends on #214187Closes#213061
### 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)
- [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: Christos Nasikas <xristosnasikas@gmail.com>
## 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>
## 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
Closes https://github.com/elastic/kibana/issues/214446
This PR introduces a new section in the span/transaction overview flyout
that will display the duration information along with a latency chart.
For now, only the duration data is included.
|Scenario||
|-|-|
|Span w/ `transaction.id`||
|Span w/o `transaction.id`||
|Transaction w/ `parent.id`||
|Transaction w/o `parent.id` (root transaction)||
Given that both spans and transactions require retrieving data from
their respective parents, a loader has been added to reflect the ongoing
data-fetching process:
## Tech details
The UI for displaying the duration and its percentage relative to the
parent is already in use in APM for spans and transactions, so the logic
is consistent with that.
To avoid duplicating components and formatters, as seen in previous PRs
for Traces in Discover, a new `Duration` component has been created in a
newly created `kbn-apm-ui-shared` package. This component will be used
in Discover and [later](https://github.com/elastic/kibana/issues/211781)
in APM as well.
## How to test
- Enable the discover profiles by adding this to the` kibana.yml `file:
```discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
- Open Discover and select or create a data view that includes any APM
traces index (`traces-*`), or query them using ES|QL.
- Apply a filter for `data_stream.type:"traces"` to ensure only trace
documents are retrieved.
- Open the flyout.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Carlos Crespo <crespocarlos@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
Bring in the changes from https://github.com/elastic/eui/pull/8304,
specifically ESLint rules:
- `no-restricted-eui-imports`
- `no-css-color` (migrated from `@kbn/eslint-plugin-css`)
- `prefer-css-attribute-for-eui-components` (migrated from
`@kbn/eslint-plugin-css`)
Relates to https://github.com/elastic/eui/issues/8201,
https://github.com/elastic/eui-private/issues/275
## QA
### Instructions
1. Checkout this branch: `gh pr checkout 210082`.
2. Reinstall dependencies: `yarn kbn bootstrap`.
3. See output of ESLint. There should be no errors.
4. Test below cases.
### Test cases
#### `no-restricted-eui-imports`
Example files:
- JSON imports: `src/platform/packages/shared/kbn-ui-theme/src/theme.ts`
- `@kbn/ui-theme`:
`src/platform/plugins/private/vis_types/vega/public/data_model/utils.ts`
#### `no-css-color`
Example file:
`src/platform/plugins/shared/kibana_react/public/page_template/no_data_page/no_data_card/elastic_agent_card.tsx:50`
#### `prefer-css-attribute-for-eui-components`
Example file:
`x-pack/examples/alerting_example/public/alert_types/always_firing.tsx:166`
## 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>
# @kbn/profiler-cli
Profile Kibana while it's running, and open the CPU profile in
Speedscope.
## Usage
Run a command by either preceding it with the profiler script:
`node scripts/profile.js -- $command`
Or by piping it in:
`$command | node scripts/profile.js`
You can also just run it until SIGINT:
`node scripts/profile.js`
Or with a timeout:
`node scripts/profile.js --timeout=10000`
## Examples
### Commands
You can copy a curl request from the browser, and place it after the
command:
`node scripts/profile.js --connections=10 --amount=50 -- curl ...`
You can also use stdin for this, for example:
`pbpaste | node scripts/profile.js`
When using stdin, take into consideration that there is some lag between
starting the script and connecting the profiler, so the profiler might
miss the first second or so of the running process.
You can also use any other command, like `autocannon`, `sleep` or
`xargs`.
### SigInt
By default, the profiler will run until the process exits:`node
scripts/profile.js`. This is useful when you have a long running process
running separately and you want to collect the profile over a longer
time period. Be aware that this might cause memory issues because the
profile will get huge. When you press Cmd+C, the profiler will
gracefully exit and first write the profile to disk and open Speedscope.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This adds an additional custom ESLint rule package which checks certain
Eui elements for the existence of an `aria-label` prop.
If it exists, it will leave it untouched. If it doesn't, it will warn
the engineer it needs to be added, and offers a autofix suggestion for
those engineers who have fix on save enabled in their IDE.
<img width="739" alt="Screenshot 2025-03-25 at 13 59 28"
src="https://github.com/user-attachments/assets/0813b317-c752-40d7-b569-e866a3ecf6b0"
/>
<img width="804" alt="Screenshot 2025-03-25 at 13 59 36"
src="https://github.com/user-attachments/assets/3c45c49c-6db8-4740-b5de-89aa534c248b"
/>
This package is an offshoot of the `kbn-eslint-plugin-i18n` and
`kbn-eslint-plugin-telemetry` packages.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- Creates a `@kbn/response-ops-rules-apis` package, following the
proposed structure for ResponseOps Management Experiences package.
- Moves relevant rules API fetchers and react-query hooks to the new
package.
- Adds an internal variant of the `/api/alerting/rule_types` endpoint
(`/internal/alerting/_rule_types`), that returns the same value as the
public one + the newly added internal [`solution`
field](https://github.com/elastic/kibana/issues/212017), that we don't
want to expose publicly.
## Verification steps
1. Create rules that fire alerts
2. Verify the usages of the moved/changed hooks, with limited privileges
as well (i.e. only `Rules Settings` but not `Stack Rules`):
2.1. Stack management and Observability rules, rule details and alerts
pages
2.2. Rules tab in the Connector editor flyout
2.3. Alerts table row actions (••• icon)
2.4. Tags filter in the rules list page
3. Using the DevTools, compare the response of the public and internal
`rule_types` endpoins:
```
GET kbn:/api/alerting/rule_types
GET kbn:/internal/alerting/_rule_types
```
Checking that the `solution` field is present only in the internal one
## References
Closes#213059
### 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>
