## Summary
This PR adds the structure for workchat FTR tests and adds a few initial
tests as an example.
### Details about initially added tests
New test directories:
- `x-pack/test_serverless/api_integration/test_suites/chat`
- load a few common tests (that run on all project types)
- run `platform` security tests (taken over from `search` project type)
- `x-pack/test_serverless/functional/services/svl_chat_navigation.ts`
- load the `home page` common test
- run a simple navigation test, using the `svlChatNavigation` service
that has been introduced as an example
Note that these tests mostly serve as examples to prove things are
actually running and will have to be adjusted / removed / extended over
time. The purpose of this PR is NOT to add proper test coverage.
Closes#213469
---------
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.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>
In this PR, I'm changing the CODEOWNERS for reporting related modules.
While reviewing, ensure I haven't missed anything or moved a module that
should remain part of sharedux team.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Tim Sullivan <tsullivan@users.noreply.github.com>
Co-authored-by: Timothy Sullivan <tsullivan@elastic.co>
## Summary
Small PR to transfer ownership of the `GroupedAlertsTable` code within
the `detections/components/alerts_table` from the
@elastic/security-threat-hunting-explore team to the
@elastic/security-threat-hunting-investigations team.
While the code was originally primarily written a developer on the
Explore team, that person has moved to a different team since then. The
Investigations team has more knowledge about how the grouped table
works, and is also primary user for it.
## 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>
> [!CAUTION]
> Do not merge yet!
> This PR is mergeable based on the assumption that we do not allow
downgrading to `search_ai_lake` tier from `essentials`/`complete` or
`trial` `complete/essentals`.
## Summary
On serverless with following sets of product types/lines timelines and
notes are not available to the user.
```json5
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' }
]
```
or
```json5
[
{ product_line: 'security', product_tier: 'search_ai_lake' }
]
```
or with
```json5
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
{ product_line: 'security', product_tier: 'search_ai_lake' }
]
```
This applies to custom role creation flyout where timelines/notes
privileges are not available for RBAC.
### Screenshots (where timeline and notes are not available)
#### Custom role creation
Also on alerts page notes and timelines is not available action items.
Trying to access these via URL does not show them either.
#### Current alerts page (with timelines and notes not available)
#### Alert details via URL (without notes on the expanded flyout)
## How to Test
1. While on the Kibana root directory, run ES/Kibana on serverless mode
with:
```bash
yarn es serverless --kill --projectType security --kibanaUrl=http://0.0.0.0:5601
```
and on a new window
```bash
yarn serverless-security --no-base-path
```
Enable the AI for SOC tier, by adding the following to your
`serverless.security.dev.yaml` file:
```json5
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
2. Once Kibana is up and running login in with the `admin` role using
the role dropdown.
3. Navigate to `app/management/roles/edit`
4. Click on `Assign to space` button and assign a space to that role on
the `Assign role to spaces` flyout.
5. Expand the `Security` privileges and verify that only 4
sub-privileges are seen and that Timelines and Notes are not among them.
### 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)
- [ ] ...
## 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
Change telemetry codeowners entry from platform-analytics to
kibana-telemetry. This somewhat expanded github team will notify
correctly while including more reviewers across orgs. Expands on change
from #214572
cc @elastic/platform-analytics
## 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>
## Summary
This PR is - at its core - only moving a handful of files around. A lot
of of these files lived under the `detections` folder, but were almost
exclusively used in files under the `detection_engine` folder. This is
why the PR seems so huge. Almost everything modified here is only files
imports...
Here are the few files that were actually moved around:
1. The files `detection_engine.tsx`, `detection_engine_no_index.tsx`,
`detection_engine_user_unauthenticated.tsx` (and their respective test
files) have been moved from
`security_solution/public/detections/pages/detection_engine` to
`security_solution/public/detections/pages/alerts`. I thought about
renaming them as well, but felt like there was already enough changes.
Renaming will be done in a follow up PR.
2. The content of the
`security_solution/public/detections/pages/detection_engine/rules`
folder was moved to `security_solution/public/detection_engine/common`
as almost the entire folder content is only used within the
`security_solution/public/detection_engine` folder.
#### Notes
_If there is a better folder for the files moved to the
`detection_engine/common` folder, feel free to suggest. I'll be happy to
make the change!_
The CODEOWNERS file has been updated and simplified accordingly.
Only imports should have been modified. No code, logic or UI changes!
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
We've done a lot of UA changes against 8.18 and 8.x but we did not port
them to `main`. The reason we did not do the active development against
`main` is because UA is disabled on main and we need those features in
8.last not on `9.0` initially. This port is to keep the codebase
consistent and to be able to use these new UA features in the future
post `9.0`.
Any issues that that are caused from this port we should wrap them in a
config and disabled them on main and enable this new flag on `8.x`.
What is being ported?
- [x] Upgrade assistant plugin
(`x-pack/platform/plugins/private/upgrade_assistant`)
- [x] Integration test changes
(`x-pack/test/upgrade_assistant_integration`)
- [x] new UA doc links
(`src/platform/packages/shared/kbn-doc-links/src/get_doc_links.ts`)
- [x] localization files sync
(`x-pack/platform/plugins/private/translations/translations/*.json`)
- [x] Unfreeze is no longer supported after `8.x`. So removed it from
data streams readonly migration step and throw an error for regular
indices migration.
Closes https://github.com/elastic/kibana/issues/210490
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/210298
In this PR we are adding the initial structure for the
@kibana/scout-security package, note that this is not ready to be used
and any new test using this package, is not going to be executed as part
of the regular pipelines, meaning, you are not going to add coverage to
the application.
@kibana/scout-security package is a test package that extends @kbn/scout
with test helpers specifically designed to test Security Solution
functionalities in Kibana. All tests under Security plugins should only
import from @kbn/scout-security, not from @kbn/scout.
This PR is a POC to start testing development by providing custom
Playwright fixtures, page objects, and utilities tailored for
Security-related testing scenarios.
Things to follow-up:
- CustomQueryRule interface is already declared in
`x-pack/solutions/security/plugins/security_solution/common/api/detection_engine/model/rule_schema/rule_schemas.gen.ts`
as `QueryRuleCreateProps`
- DETECTION_ENGINE_RULES_URL and DETECTION_ENGINE_RULES_BULK_ACTION are
already declared in `@kbn/security-solution-plugin/common/constants`
It would be great if all of that is extracted from the plugin to a
package so it can be reused instead of having to duplicate the code.
Until the package is not ready to be used and has not been introduced to
the different teams, appex-qa and myself will be the owners of it to
make sure that best practices are followed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
Creates a wrapper plugin around the alerts table, that registers a basic
alerts table embeddable panel for dashboards.
> [!NOTE]
> This PR is a preparation work for the [embeddable alerts
table](https://github.com/elastic/kibana/issues/197483). The feature is
disabled for end-users while waiting for other dependent PRs to be
integrated with this, and uses a partially hard-coded table
configuration for testing purposes. The final panel will be fully
configurable by the user.
## Verification steps
1. Uncomment this line
4d49e98b4d/x-pack/platform/plugins/shared/embeddable_alerts_table/public/plugin.ts (L34)
(I'm using a comment to avoid polluting the embeddable examples app with
this panel for a short time)
2. Create one or more ES Query rules that fire alerts
3. Visit the Dashboards page and create a dashboard, then enter edit
mode
4. Click "Add panel"
5. Under "Visualizations" choose "Alerts table"
6. Check that the table panel was created correctly
6.1. Shows any alerts fired by the ES Query rule(s)
6.2. Check that the table adapts correctly to the panel when resizing,
and all normal interactions with the alerts table work correctly
(adding/removing fields, opening alerts in flyouts, using row/bulk
actions)
6.3. Check that panels respond to the global time filter (only time
filters, not KQL search or filters)
6.4. Check that panels respond to individual time filters (⛭ icon >
Apply custom time range)
11. Create a role with access to dashboards but without any alerting
capability and a user assigned to that role
12. Repeat steps 3 and 4, and verify that the "Alerts table" option
isn't available under "Visualizations"
13. Add any alerting capability to the role, such as Management > Stack
rules
14. Repeat steps 3 and 4, and verify that the "Alerts table" is
available again
## References
Closes#203611
### 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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR establishes the foundation for executing API tests in the new
`search_ai_lake` tier, following the existing API integration test
structure and guidelines.
## Adding a New Test
To add a new test, follow these guidelines:
- Inside the `AI4DSOC` folder, create subfolders representing different
AI4DSOC functionalities.
- Each subfolder should be owned by an area team or the developers
actively working on it.
- The functionality folder must include a `search_ai_lake_tier`
subfolder.
- The `search_ai_lake_tier` subfolder should contain a `configs`
directory with a `serverless.config.ts` file that imports
`createTestConfig` from `config.base.ai4dsoc`.
- Add the test inside the `search_ai_lake_tier` subfolder.
- Ensure the test has the `@serverless` label and uses
`supertestWithoutAuth` instead of `supertest`, as `supertest` provides
basic authentication, whereas serverless environments require API key
authentication. See the `dummy_test.ts` for reference.
- The `search_ai_lake_tier` folder should have an `index.ts` file
referencing the tests to be executed, as demonstrated in this PR.
- Update the
`x-pack/test/security_solution_api_integration/package.json` file with
the necessary scripts to enable test execution locally.
- When adding a new `serverless.config.ts` file, ensure it is included
in `.buildkite/ftr_security_serverless_configs.yml`. Otherwise, the new
test(s) will not be executed as part of the PR process.
## Running Tests Locally
Execute the tests using the following Yarn scripts from
`x-pack/test/security_solution_api_integration`:
1. Start the server with the required configuration:
```sh
yarn ai4dsoc_cases:server:serverless
```
2. Run the tests using the started server:
```sh
yarn ai4dsoc_cases🏃serverless
```
## Key Considerations
- `Supertest` should not be used, as it provides basic authentication.
Instead, use supertestWithoutAuth for API key authentication.
- All tests must include the `@serverless` label.
- MKI is not yet supported for test execution.
- Temporary Ownership: The Security Engineering Productivity team will
initially own the AI4DSOC testing folder to ensure proper structure and
best practices. Once teams are familiar with the workflow, this
ownership will be removed.
## Security Engineering Productivity Code Ownership Responsibilities
The Security Engineering Productivity team should ensure:
- All tests are placed inside a functionality-specific subfolder.
- Each functionality subfolder has designated code owners.
- Tests include the `@serverless` label.
- `Supertest` is not used.
- The correct configuration is applied.
- Scripts are added to enable local execution.
- New configurations are added to
`.buildkite/ftr_security_serverless_configs.yml`.
## Follow-Up tasks
- Remove the existing dummy test.
- Integrate tests into the periodic pipeline.
- Add tests to the Kibana QA quality gate.
## Summary
This PR is the setting the foundations for the AI for SOC Alert summary
page. It has very little UI, instead it focuses on the following:
- add routing for the `alert_summary` page
- fetches the integrations, filters them to only keep the ones related
to AI for SOC, then decides what to render depending on if some AI for
SOC packages have been installed or not
The PR also makes a small change to the `SecurityRoutePageWrapper`
component, to allow us to redirect to the Security Solution HomePage
instead of the NoPrivilegesPage. While this might not be a long term
solution, it is the easiest path forward. In the future, AI for SOC will
most likely be its own plugin (leaving outside of Security Solution)
hence this will not be needed anymore.
Here's the basic behavior of the Alert summary page:
- The `Landing page` will be shown if none of the hardcoded AI for SOC
packages are installed (these values are hardcoded as we currently do
not have a way to filter integrations for the AI for SOC ones only):
- splunk // doesnt yet exist
- google_secops
- microsoft_sentinel
- sentinel_one
- crowdstrike
- The `Wrapper` component will only be shown if you have at least one of
the above AI for SOC packages installed.
### Very limited UI added in this PR
| Loading integrations | No installed packages | Some installed packages
|
| ------------- | ------------- | ------------- |
| 
| 
| 
|
### Notes
We need to remove the section at the top of the page that currently
shows the `Add integrations` button. A follow PR will take care of that.
[This](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/security_solution/public/app/home/index.tsx#L54)
is where that bar is being added. We will have to find a way to not show
that for the AI for SOC tier.
## How to test
This needs to be ran in Serverless:
- `yarn es serverless --projectType security`
- `yarn serverless-security --no-base-path`
You also need to enable the AI for SOC tier, by adding the following to
your `serverless.security.dev.yaml` file:
```
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
The Alert summary navigation will NOT be shown for the following
Serverless users: `viewer`, `t1_analyst`.
and `t2_analyst`. For those, the navigation entry is not present, and
navigating to the url directly will automatically re-route to the
Security home page.
Currently, retrieving the integrations (via the `fleet/epm/packages`
endpoint) is also unauthorized for the following users: `editor`,
`t3_analyst`, `threat_intelligence_analyst`, `rule_author`,
`soc_manager` and `detections_admin`.
This means that the only users that can be currently used to test this
PR are:
- `platform_engineer`
- `endpoint_operations_analyst`
- `endpoint_policy_manager`
- `admin`
- `system_indices_superuser`
### 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
Will help close https://github.com/elastic/security-team/issues/11954 as
well as https://github.com/elastic/security-team/issues/11979.
## Summary
The intent is to have a centralised place to store the list of Kibana
solutions and serverless project types.
To that end, this PR creates a `@kbn/projects-solutions-groups` package.
It also adds the new solution type `'chat'`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR reworks how APM handles getting its sources data, elevating the
necessary code to a private shared plugin so that Discover for Traces
can access the data and handle user provided configuration. It also
removes the need for Discover for Traces to rely on the APM static data
view, so the Trace data source and document profile will work on any
compatible/configured index, even in ESQL mode.
Closes#211414
<img alt="ESQL Discover Traces Screenshot 2025-03-04 173032"
src="https://github.com/user-attachments/assets/f5bbb736-8b8b-45dc-ac23-4bf7083aa47e"
/>
## How to test
Test with olbt-cli instance for now, will post for doing with synthtrace
data. Ensure the following is added to your kibana.dev.yml:
```yaml
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
```
- Make sure your space has the Observability solution view configured
- Go to Discover page
- Select Data Views mode if required and create a view with a `traces`
specific index. Or use the APM static data view.
- The default columns on the page should show the summary column with
four of the following badges: `service.name`, `event.outcome`,
`transaction.name`, `transaction.duration.us`, `span.name`,
`span.duration.us`
- Go to ESQL mode with the query targetting a `traces` index
- The default columns should show the same as in Data View mode
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Irene Blanco <irene.blanco@elastic.co>
## Summary
This PR establishes the baseline to execute Cypress tests in the new
`search_ai_lake` tier.
## Changes Introduced
- All tests under
`x-pack/test/security_solution_cypress/cypress/e2e/ai4dsoc` will be
executed using the new tier by default.
- These tests will run as part of the PR process within the `Serverless
AI4DSOC - Security Solution Cypress Tests` execution.
## Adding a New Test
To add a new test, follow these guidelines:
- Read the
[README](x-pack/test/security_solution_cypress/cypress/e2e/ai4dsoc/README.md).
- Inside the `AI4DSOC` folder, we should have different subfolders
representing the various AI4DSOC functionalities.
- Each subfolder should have ownership by either an area team or the
developers actively working on it.
- Make sure that any functionality you want to be tested in the new tier
is added inside the `AI4DSOC` folder; otherwise, that functionality will
be tested using the complete tier.
## Running Tests Locally
Run the tests with the following Yarn scripts from
`x-pack/test/security_solution_cypress`:
```sh
yarn cypress:open:ai4dsoc:serverless
```
Opens the Cypress UI with all tests in the `e2e/ai4dsoc` directory. This
also runs a mocked serverless environment using the `ai_soc` product
line and `search_ai_lake` tier by default.
```sh
yarn cypress:run:ai4dsoc:serverless
```
Runs all tests tagged as @serverless in the e2e/ai4dsoc directory in
headless mode using the ai_soc product line and search_ai_lake tier by
default.
## Key Considerations
- All tests must have the `@serverless` tag to be executed as part of
the PR process.
- MKI is not yet supported for test execution.
- The AI4DSOC Cypress tests will be executed each time there is a change
in one of its
[dependencies](https://github.com/elastic/kibana/blob/main/.buildkite/scripts/pipelines/pull_request/pipeline.ts).
- All tests are executed by default using the `platform_engineer` role.
- Temporary Ownership: The Security Engineering Productivity team will
own the entire AI4DSOC testing folder initially to ensure structure and
best practices. Once all teams understand the workflow, this ownership
will be removed.
- Execution Time: If test execution in a PR takes more than 45 minutes,
parallelism should be increased in the new
`.buildkite/pipelines/pull_request/security_solution/ai4dsoc.yml` file.
## Security Engineering Productivity Codeownership Responsibilities
The Security Engineering Productivity team should ensure:
- Best practices are followed.
- All tests are placed inside a functionality subfolder.
- Each functionality subfolder has designated code owners.
- Tests include the `@serverless` label.
- The execution of AI4DSOC tests does not exceed 45 minutes.
## Follow-Up Tasks
- Remove the dummy test (@tomsonpl feel free to delete it when you need
to add new tests to the navigation).
- Integrate tests into the periodic pipeline.
- Add tests to the Kibana QA quality gate.
- Update the README with MKI instructions once tests are added to the
periodic pipeline and Kibana QA quality gate.
- Clarify which roles will be used for the AI4DSOC effort and update the
tests accordingly.
## Summary
Closes https://github.com/elastic/streams-program/issues/170 and
https://github.com/elastic/streams-program/issues/171
## Reviewer notes
It's worth reading the research in
https://github.com/elastic/streams-program/issues/168 to understand why
certain decisions were made. Some of the resolving code is inspired by
`grok-js`, unfortunately this wasn't something we could use directly.
The design / UX is **not** final. This is just a functional version. The
editor is currently on the streams > enrichment page so it can be played
with, this will **not** be merged.
There is pattern support for our ECS patterns, I have not added the
legacy ones.
There will almost certainly be some edge cases that don't work, every
repo for a Grok tool I looked at had their own 😅 I've tried to test this
with lots of varied examples though.
I'd recommend unticking "No extension" from the file filter to remove
the pattern files.
<img width="323" alt="Screenshot 2025-03-06 at 22 40 19"
src="https://github.com/user-attachments/assets/5b594f5f-0b0f-4ed0-ae10-2412fcf9e31a"
/>
## Possible improvements / followups
- We could in the future expand the UI to toggle on and off certain
pattern collections.
- Ability to add custom patterns (like in our Grok debugger). This can
still be achieved with `(?<queue_id>[0-9A-F]{10,11})` syntax.
- Point out when regex is invalid (right now it's silent).
- I've copied over the patterns from the ES repo for now, with a light
script to generate an object from them. There's a CLI skeleton in place
if we feel we want to actually pull these from the ES repo directly.
These patterns don't change often, and aren't heavy size wise.
- Debouncing etc for processing, but I'd like to see how the final UX
ends up.
## Media
Screenshot
Simple example
Complex example
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
More teams are adding Scout tests in their plugins, often as a PoC and
not stable yet for continuous execution.
We don't want to block it, but need a way to manage the scope of Scout
pipeline and be able to disable it quickly to unblock the Scout
development.
Since Scout is in active development and we need it to be simple and
quick as possible (we can iterate and improve later), we agreed with
Robert to disable tests by plugin:
```
ui_tests:
enabled:
- apm
- discover_enhanced
- maps
- observability_onboarding
disabled:
- *skipped_plugin*
```
When scout configuration is added to the new plugin, it will require to
update `.buildkite/scout_ci_config.yml` that is owned by `appex-qa`
team. If there is no intention to run Scout tests on CI, plugin name
should be added under `disabled` section.
**How to test locally:**
- Scout tests were added in `observability_onboarding` plugin, pipeline
will throw error
modify locally `.buildkite/scout_ci_config.yml`
```
ui_tests:
enabled:
- apm
- discover_enhanced
- maps
disabled:
```
run `node scripts/scout discover-playwright-configs --validate --save`
```
ERROR The following plugins are not registered in Scout CI config '.buildkite/scout_ci_config.yml'
- observability_onboarding
```
~~On CI annotation will be added to clarify the failure:~~
we decided to move validation to "Quick Checks", no need to annotate.
<img width="1583" alt="image"
src="https://github.com/user-attachments/assets/ed6b5778-74cb-4473-8218-b96239aab067"
/>
- `observability_onboarding` plugin is disabled, pipeline won't include
it (excluded in `scout_playwright_configs.json`)
modify locally `.buildkite/scout_ci_config.yml`
```
ui_tests:
enabled:
- apm
- discover_enhanced
- maps
disabled:
- observability_onboarding
```
run `node scripts/scout discover-playwright-configs --validate --save`
```
warn The following plugins are disabled in '.buildkite/scout_ci_config.yml' and will be excluded from CI run
- observability_onboarding
info Found Playwright config files in '4' plugins.
Saved '3' plugins to '/Users/dmle/github/kibana/.scout/test_configs/scout_playwright_configs.json'
```
Exposes an Inference (plugin) API client for scripts, that mimicks the
`chatComplete` and `output` APIs that are available on its start
contract. It depends on the KibanaClient that is exposed from the
`@kbn/kibana-api-cli` package. It automatically selects a connector if
available.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Changing code owners as discussed with @thomasneirynck and @davismcphee.
I also bumped CPU time limit as it fails few times passing over `1.55`
sec.
## Summary
Adds a basic api for finding suggested dashboards by alert.
This internal API is currently not in use anywhere.
This api finds suggested dashboards in two ways:
1. Finding dashboards with lens visualizations that query against the
same data view
2. Finding dashboards with lens visualizations that utilize fields in
the rule configuration, or alert data.
These are two naive approaches to finding suggested dashboards. These
heuristics will be improved over time and incorporate more sophisticated
approaches that have been explored by numerous engineers across
Observability.
## Testing
A basic api integration test is included that covers matching dashboards
by index and field, across spaces. As we develop this feature further
over time more fine grain tests will be added
### Manual Testing
1. Run
```
node x-pack/scripts/data_forge.js --events-per-cycle 200 --lookback now-1h --ephemeral-project-ids 10 --dataset fake_stack --install-kibana-assets --kibana-url http://localhost:5601 --event-template bad
```
2. Save the file as a .ndjson file and import it via saved objects
import
https://p.elstc.co/paste/3BWKIHLU#f0WfGYx7G9DhWy88yDXhaEXTX16Fn+ovDcomNIx6E3a
3. Navigate to the alert details page, you should start to see a lot of
alerts
4. Click on one, and copy the alert id
5. Navigate to console and paste `GET
kbn:/internal/observability/alerts/suggested_dashboards?alertId=[YOUR_ALERT_ID]`
to see the recommended dashboards
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Nick Peihl <nickpeihl@gmail.com>
## Summary
Closes https://github.com/elastic/kibana/issues/213216
This PR adds the functionality to properly highlight filtered values
within badges.
Previously, the content was treated as `text` instead of `html`, which
prevented the highlighted values from being displayed correctly.
The content is now rendered with the `<mark>` tag, allowing matching
values to be properly highlighted within the badges.
>[!NOTE]
>By looking at the code I assumed the `<mark>` tag is the only one we
introduce, so the proposed solution only handles that.
|Before|After|
|-|-|
|||
### How to test
- Make sure you are in a space with Observability as solution view
- Select the "All logs" data view
- Add any filter that matches the displayed badges value
## Summary
Depends on #191106Closes#171591
This PR migrates Storybook from `6.x` to `8.x`. Please see the
[migration
guide](https://storybook.js.org/docs/migration-guide/from-older-version)
for an overview of the changes because there are many breaking changes
which effect Kibana. The TODO list below is not inclusive of all the
changes.
## Reviewers
### Each commit contains all files changed for a specific codeowner,
please find your respective commit to make review easier.
A **first step before code review** should be checking the [`Storybooks
Preview`](https://ci-artifacts.kibana.dev/storybooks/pr-195148/index.html)
from CI for any runtime or style issues which were missed. The preview
can be compared to a build from `main`
[here](https://ci-artifacts.kibana.dev/storybooks/pr-212585/index.html).
It is worth noting that some stories have runtime issues which existed
before this migration.
Most stories appear to have been migrated properly, but the Operations
team does not have prior knowledge into every story. Some of the
migration was able to be automated through Storybook provided scripts.
It is possible this wasn't entirely correct due to the structure of some
stories. Additionally, part of this migration is moving Storybook to
Webpack 5 which changed how styles are being loaded.
#### TODO
- [x] Migrate `stories.mdx`
- [x] storyshots
- [x] [Migrate
packages](https://storybook.js.org/docs/migration-guide/from-older-version#package-structure-changes)
which were removed in `8.0`
- [x] `react-doc-gen` resolution
- [x] [Migrate
blocks](https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#addon-docs-removed-deprecated-blocksjs-entry)
- [x] Migrate deprecated `addon-knobs` to
[addon-controls](https://www.npmjs.com/package/@storybook/addon-controls)
- [x] React Fast Refresh support
- [x] Watch flag callback
- [x] `canvas` webpack
- [x] Rerun CSF migrations for new stories
- [x] Handle ESM import for `addon-docs`
- [x] `'@storybook/addon-actions' should be listed in the project's
dependencies. Run 'npm i -S @storybook/addon-actions' to add
iteslint[import/no-extraneous-dependencies](https://github.com/import-js/eslint-plugin-import/blob/v2.28.0/docs/rules/no-extraneous-dependencies.md)`
- [x] `addDecorator` migration
- [x] `addParameter` migration
- [x] static build
- [ ] determine if #176500 is solved or push to followup PR
- This will need to be fixed separately
- [x] revert `.buildkite/pipelines/pull_request/base.yml` &
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to `main`
---------
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jacek Kolezynski <jacek.kolezynski@elastic.co>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Co-authored-by: Clint Andrew Hall <clint@clintandrewhall.com>
## Summary
Adds `@elastic/platform-analytics` as codeowners of the telemetry
schemas to raise awareness of any changes implemented in the snapshot
telemetry.
The end goal is to remove Kibana Core from owning them.
Closes#197953
## Summary
This PR replaces the alert status filter with filter controls. In this
PR, I also covered backward compatibility when we have a `status` URL
parameter by passing that value to filters, as shown below:
|State|Screenshot|
|---|---|
|Before||
|After||
https://github.com/user-attachments/assets/86e82a19-f68e-4127-9fd8-e0efe0d41ece
I checked in Serverless and we have access to controls in viewer mode as
well:
https://github.com/user-attachments/assets/2c90ba3a-7d95-4682-b722-e5b327f7334d
### 🐞 Known issue
1. Privilege
In Stateful, if a user has Kibana privilege but not the `.alert*` es
privilege, then the controls do not work as expected. This issue will be
tackled in a separate ticket:
<details>
<summary>This is the error that we show in this scenario</summary>
</details>
2. Initial load
Related ticket: https://github.com/elastic/kibana/issues/183412
### 🗒️ Tasks
- [x] ~~Solving the permission issue~~ This issue does not happen in
Serverless and for stateful, we will fix it in a separate ticket:
https://github.com/elastic/kibana/issues/208225
- The main issue will be fixed in this
[PR](https://github.com/elastic/kibana/pull/191110)
- In the above [PR](https://github.com/elastic/kibana/pull/191110), we
remove controls if the user does not have the privilege for alert
indices, but we need to figure out how to adjust filter controls to
access the data based on Kibana privileges.
- [x] We should configure the filters to allow the selection of one item
for alert status but still show the other options
- [x] We need to see how we can make this work with the current status
field. Ideally, if there is a status field, we would apply it and remove
it from the URL.
- Fixed in
[c6cad2d](c6cad2dbe1)
- [x] Changing the URL does not update the page filters correctly. ~~It
might be related to https://github.com/elastic/kibana/issues/183412.~~
- [x] We need to make sure these adjustments work as expected in APM as
they use the observability alert search bar.
- [x] Check if the tags filter can be improved, and if not, whether it
makes sense to keep it in its current form.
- It works based on how array filtering works in ES, which seems like a
good start to me.
- [x] Check with Maciej: Do we need to disable changing control configs?
- Checked with Maciej: it is fine to keep the option of editing
controls.
- [x] Do we need to have a different local storage item for each page
(apm/rule details/alert details/alerts)?
- How can we disable syncing with the local storage?
- Added the possibility of disabling sync in
[24bab21](24bab210b0)
and disabled it for the rule details and alert details pages.
- Also, disabled it for the APM alert search bar.
- [x] Setting default status as active on the related alerts tab
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
Replaces #213441
## Summary
@smith and I have agreed that it makes sense for the infra services team
to own the observability overview page within the obs plugin.
First PR didn't add the changes to the correct "overrides" section of
the CODEOWNERS file.
Co-authored-by: Maryam Saeidi <maryam.saeidi@elastic.co>
## Summary
Closes - https://github.com/elastic/kibana/issues/166679
## What's included ?
- The PR adds a feature in Logs View of Observability (to start with) to
hide the regular pagination toolbar from the footer and show Load More
only when the user has scrolled to the bottom of the page.
- The table would always load the items in batches of default set 500
- This PR also add 2 helper functions `useThrottleFn` and
`useDebounceFn`. Current React help library which KIbana uses called
-`react-use` does not have these and we cannot use Lodash variant of
these. We need such hooks which are React safe. Hence added these 2
## What's pending ?
- [x] Unit tests for the 2 new helper React hooks
- [x] Unit tests for data table footer component
- [x] Unit tests for Profile Resolution
- [x] Functional Serverless Tests
- [x] Functional Stateful Tests
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Davis McPhee <davismcphee@hotmail.com>
Co-authored-by: Felix Stürmer <weltenwort@users.noreply.github.com>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
Download, parse and replay loghub data with Synthtrace, for use in the
Streams project. In summary:
- adds a `@kbn/sample-log-parser` package which parses Loghub sample
data, creates valid parsers for extracting and replacing timestamps,
using the LLM
- add a `sample_logs` scenario which uses the parsed data sets to replay
Loghub data continuously as if it were live data
- refactor some parts of Synthtrace (follow-up work captured in
https://github.com/elastic/kibana/issues/212179)
## Synthtrace changes
- Replace custom Logger object with Kibana-standard ToolingLog
- Report progress and estimated time to completion for long-running jobs
- Simplify scenarioOpts (allow comma-separated key-value pairs instead
of just JSON)
- Simplify client initialization
- When using workers, only bootstrap once (in the main thread)
- Allow workers to gracefully shutdown
- Downgrade some logging levels for less noise
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves#212919
We noticed that setting the header `'Content-Type':
'text/event-stream',` didn't work as the browser's native EventSource
implementation.
```JS
return res.ok({
headers: {
'Content-Type': 'text/event-stream',
'Cache-Control': 'no-cache',
},
body: observableIntoEventSourceStream(events$ as unknown as Observable<ServerSentEvent>, {
signal: abortController.signal,
logger,
}),
});
```
The reason, apparently, is that we need to flush the compressor's buffer
negotiated in the HTTP request.
### How to test it:
Run Kibana with examples `yarn start --no-base-path --run-examples
--http2` and open the SSE example app in Kibana. You should see a clock
updating every second in the UI (the clock is coming from the server).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/211778 and
https://github.com/elastic/kibana/issues/211871
This PR is a follow-up to issue
[#208693](https://github.com/elastic/kibana/issues/208693) and
incorporates the suggestions from its associated PR
[#210612](https://github.com/elastic/kibana/pull/210612).
>[!NOTE]
> Please note that most of the changes in this PR involve moving files,
renaming `data-test-subj` attributes, updating imports, and not creating
the files from scratch.
**What's happening in this PR?**
- Transitioning from data source profile to document profile.
- Splitting the traces document viewer into separate span and
transaction viewers.
- Enhancing the `useTransaction` hook to abort requests on component
unmount.
As noted in the `TODOs`, a follow-up issue will focus on using for
APM-configured indexes to enable the experience and retrieve the
`transaction.name` for spans.
### How to test
Add this to your kibana.dev.yml:
```
discover.experimental.enabledProfiles:
- observability-traces-span-document-profile
- observability-traces-transaction-document-profile
`````
- Go to Discover page
- Select APM data view
- Check your traces data
- Spans and transactions should show the new overview tabs when opening
the flyout
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Cauê Marcondes <55978943+cauemarcondes@users.noreply.github.com>
Co-authored-by: Carlos Crespo <crespocarlos@users.noreply.github.com>
