The action is getting skipped on backports and I suspect we were not
checking correctly for the pr author. I changed it a little to make sure
we are getting the pr author through the head ref so we can validate is
being created by kibanamachine.
Closes#159833
## Summary
Adds tests to verify the default serverless security response headers
are present in API and redirect responses.
- Adds
`x-pack/test_serverless/api_integration/test_suites/common/security_response_headers.ts`
- Modifies CODEOWNERS to designate `elastic/kibana-security` as the
owner of these tests
## Summary
Adds a GitHub workflow/action for auto-approving backport PRs incoming
from kibanamachine.
These changes are already reviewed by an owner when it was merged to
`main` - afterward the `kibanamachine` creates the PR to the non-main
branches, these can be auto-approved when created, so that the backport
automation is working without assistance.
## 📓 Summary
Closes https://github.com/elastic/observability-dev/issues/2655
This PR introduces a customized log consumption experience in the
Discover plugin. By leveraging the new `discover_log_explorer` plugin
and utilizing the `discover.customize` functionality, we have curated a
more tailored user experience.
The key feature of this implementation is the `DatasetSelector`
component, which replaces the original Discover `DataViewPicker`. It
handles the retrieval, rendering, and navigation of integrations and
data streams related to logs, providing an improved user interface.
This PR involves significant development efforts, including the creation
of the `discover_log_explorer` plugin, implementation of services, state
machines, custom hooks, and enhancements to presentational components.
The following overview will help reviewers understand the
responsibilities of each component in this implementation.
d725b699-452e-4718-8189-8dc1fab4d044
## DatasetsService & DatasetsClient
The DatasetsService is introduced, a crucial component that mediates
access to the newly implemented DatasetsClient. During the plugin's
lifecycle, the DatasetsService exposes a client property through its
start() method, providing convenient access to a DatasetsClient
instance.
The DatasetsClient is responsible for abstracting the data fetching
process for two endpoints: the integrations endpoint and the data
streams listing endpoint. These endpoints are utilized to populate the
selector options in the user interface. To facilitate this, the
DatasetsClient exposes the findIntegrations and findDatasets methods,
which handle the respective data fetching.
## Discover Customization
The critical part of this work consists of where the customization is
applied.
Inside the `public/plugin.tsx`, we lazy load and create, injecting the
required dependencies, the `CustomDatasetSelector`, which already
encapsulates all the logic required to make the selector work with the
external APIs.
We kept separating the data fetching logic from how the selector works,
and all the data and events are passed into the UI component with
properties.
```ts
discover.customize(
DISCOVER_LOG_EXPLORER_PROFILE_ID,
({ customizations, stateContainer }) => {
customizations.set({
id: 'search_bar',
CustomDataViewPicker: createLazyCustomDatasetSelector({
datasetsClient: datasetsService.client,
stateContainer,
}),
});
...
```
## Data fetching state machines & custom hooks
To handle the data fetching of integrations and unmanaged data streams,
we created two different state machines to separately handle the related
action for each dataset, such as remote search, in-memory search, error
handling etc.
### Integration machine and useIntegrations
The integrations state machine handles automatic data fetching of the
resources and additionally provides transitions for loading more
integrations, searching integrations by HTTP request, searching locally
into integration streams, and all the related loading and error handling
states.
It is then interpreted inside the `useIntegrations` custom hook, which
exposes the fetched data and handlers for all the above-mentioned
actions.
<img width="1975" alt="Screenshot 2023-05-30 at 09 44 42"
src="6daeca9f-826d-4a0f-bd90-eb4826ed1bde">
### Datasets machine and useDatasets
Similar to the integrations state machine, but simplified since the data
streams search can only happen with HTTP requests and there is no
pagination that requires to handle the load of more entries.
It is interpreted inside the `useDatasets` custom hook, which also
exposes the fetched data and handlers for the available actions.
<img width="1692" alt="Screenshot 2023-05-30 at 09 45 11"
src="5f9690e2-4e8f-439e-9ffd-f3b34cf3eaf5">
## DatasetSelector
The `DatasetSelector` component contains all the logic that manages the
navigation and searches across the different panels that render
integrations, integrations' streams or unmanaged streams.
As the datasets come from different APIs or are performed in-memory, the
search work follow this logic:
- When listing the integrations list (first level of the
`EuiContextMenu`), the search is done with an HTTP request.
- When listing the data streams list for a specific integration (second
level of the `EuiContextMenu`), the search is done in-memory, filtering
and sorting directly in the client.
- When listing the unmanaged data streams list (second level of the
`EuiContextMenu`), the search is done again with an HTTP request.
To handle these possible user journeys correctly without side effects,
we created another state machine and exposed its actions with an
internal `useDatasetSelector` custom hook.
<img width="1978" alt="Screenshot 2023-05-30 at 09 46 04"
src="84aa4247-c65d-40de-9eb6-6117bee731f8">
## Next steps
This component will change quite a lot until we won't get to a final
design. As soon as a first solid mvp is defined for production, a
complete test for the component will be implemented, among with a more
generic functional test for the core customization features.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Co-authored-by: Felix Stürmer <weltenwort@users.noreply.github.com>
As part of the actions for making Profiling production ready, this PR
adds basic API tests on the Profiling APIs checking if only users with
`access:profiling` are allowed to call our APIs, other users must be
forbidden.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/159410
This PR adds a new package `kbn-generate-console-definitions` that will
eventually replace the package `kbn-spec-to-console`. It also adds a new
command to use the script in the new package. The new command can be
used as following:
- `node scripts/generate_console_definitions.js --source
<PATH_TO_ES_SPECIFICATION_REPO>` where `PATH_TO_ES_SPECIFICATION_FOLDER`
is the absolute path to the root of the [ES specification
repo](https://github.com/elastic/elasticsearch-specification), for
example `/Users/yulia/elastic/elasticsearch-specification`. This command
will generate autocomplete definitions in the folder
`KIBANA_ROOT/src/plugins/console/server/lib/json/generated`.
- Optionally `--dest` parameter can be passed to generate definitions in
a different folder, relative to `KIBANA_ROOT`.
Basic script functionality was implemented in this PR:
- [x] Create the folder if doesn't exist yet
- [x] Remove all files in the folder before generating definitions
- [x] Load the specification schema and parse each endpoint
- [x] Create a file for each endpoint with the endpoint name, methods,
patterns and doc urls.
Functionality that will be added in follow up PRs:
- Url paramaters
- Request body parameters
- Availability property
- Unit test for script functions
### How to test
1. Checkout ES specification repo
2. Run the command with `node scripts/generate_console_definitions.js
--source <ES_SPECIFICATION_REPO> --emptyDest` where
`<ES_SPECIFICATION_REPO>` is the absolute path to the root of the ES
specification repo
3. Check the changes to the generated files in the folder
`/KIBANA_REPO/src/plugins/console/server/lib/spec_definitions/json/generated`
and make sure they have a correct endpoint name, patterns, methods and
doc links. We are not generating any url params, request body params or
availability property for now.
4. Change the constant in the file
`KIBANA_REPO/src/plugins/console/common/constants/autocomplete_definitions.ts`
to a non-existent folder. Run the script `node
scripts/generate_console_definitions.js --source
<ES_SPECIFICATION_REPO>` and check that the folder has been created
successfully
5. Re-run the command without `--emptyDest` flag targeting a folder that
already contain some files. Check that the script fails and doesn't
silently remove existing files
6. Run the help command `node scripts/generate_console_definitions.js
--help` and check if the help message makes sense
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Alison Goryachev <alisonmllr20@gmail.com>
- Closes https://github.com/elastic/kibana/issues/149336
## Summary
This PR converts `unifiedFieldList` plugin into a new
`@kbn/unified-field-list` package.
Had to also move some deps:
- from `uiActions` plugin to the existing `@kbn/ui-actions-browser`
package
- from `data` plugin to a new `@kbn/data-service` package
Please test that Field Stats from the package are still working on your
pages.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The actionable Observability team is taking over the ownership of rule
types in the observability solution. This PR changes the ownership of
alerting logic in the Infra plugin.
Changes the code owner for the Kibana docs link service to `@elastic/docs`.
The file currently lists `@elastic/kibana-docs` as the owner. However, that team now focuses solely on Kibana platform docs.
The package contains doc links for anything housed in Kibana — including solutions with dedicated doc teams. The `@elastic/kibana-docs` team often blocks related PRs from these teams.
**Resolves: https://github.com/elastic/security-team/issues/6867**
(internal)
## Summary
**TL;DR**: This PR introduces a folder for storing and working on test
plans for Security Solution inside the Kibana repo.
Instead of using Google Docs for collaborating on test plans,
@elastic/security-detection-rule-management folks have decided to
leverage standard GitHub workflow. This should give us the following
benefits:
- Right now it's hard to find the test plans you want to check. Most of
them are stored in Google Drive and are not shared across the whole
Elastic or Security orgs. Keeping them within the `security_solution`
plugin in the open repo would make it much easier and straightforward to
navigate the test plans.
- Additionally. we will start linking tickets and PRs to our test plans
which will provide more context to them.
- With Google Docs it's often not clear who should review a test plan,
who and when approved it, and whether it's done or still in progress.
The GitHub workflow solves these and other issues, and eliminates the
need to have a different workflow for test plans.
- GitHub's UX is superior to Google Docs UX when it comes to commenting.
See the ticket and the `README.md` in the PR's diff for more info.
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
## Summary
[This PR copies off of this one which adds a config for Investigations,
but instead adds one for
Explore.](https://github.com/elastic/kibana/pull/158236)
In this PR following this issue:
https://github.com/elastic/kibana/issues/153661 we are creating a
Cypress execution just for the `Explore` team. That would help the teams
to improve their ownership of the tests.
- This PR moves one Explore test to the new directory. We plan to move
them all in a follow up PR.
- We are updating the codeowners file to reflect this new change.
- We are creating a new script that runs just the explore team.
- We are doing all the necessary changes to have all the tests inside
the new explore folder executed on the CI
- We are adding this new execution to the unsupported ftrs execution
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Partially address https://github.com/elastic/kibana/issues/158835, add
cloud chat (drift) to more places: all management pages and
home/getting_started page
I hit an issue that both management and home couldn't depend directly on
`cloudChat` plugin. Here is the issue with more details
https://github.com/elastic/kibana/issues/159008. I worked around with
creating an intermediate `cloudChatProvider` plugin.
How do I run drift locally?
Add this to kibana.yml
```
xpack.cloud.id: "some-id"
xpack.cloud.trial_end_date: "2023-06-21T00:00:00.000Z"
xpack.cloud_integrations.chat.enabled: true
xpack.cloud_integrations.chat.chatURL: "https://elasticcloud-production-chat-us-east-1.s3.amazonaws.com/drift-iframe.html"
xpack.cloud_integrations.chat.chatIdentitySecret: "some-secret" (get it from drift console)
```
You need to have access to our drift account. But I tested with a custom
account. To change account id I had to point
`xpack.cloud_integrations.chat.chatURL` to a script with custom drift
id.
Refactors outdated approach of sharing the custom data grid component
from the `ml` plugin to the `transform` plugin to use packages instead.
Creates the following packages:
- `@kbn/ml-data-grid`
- `@kbn/ml-date-utils`
- `@kbn/ml-runtime-field-utils`
----
- Imports have been refactored so the `transform` plugin no longer
imports code from packages `@kbn/ml-anomaly-utils` and
`@kbn/ml-data-frame-analytics-utils`.
- Removed again auto-generated `@type` related JSDoc comments. Within
the code those annotations are quite redundant, would be cumbersome to
maintain and they are not necessary to satisfy the "missing comments"
check.
- The `renderCellPopover` callback has been refactored out of the
`DataGrid` component and can now be passed in as an optional prop. It is
only used for Data Frame Analytics and this way we can avoid some
dependency of the transform plugin on DFA related code.
- Some more code has been moved to `@kbn/ml-anomaly-utils` to make
available via packages what's needed for the data grid.
## [Security Solution] Elastic Security Assistant
The _Elastic Security Assistant_ has entered the chat, integrating generative AI and large language models (LLMs) into the workflows of Elastic Security users.
Bring your alerts, events, rules, and data quality checks into the conversation.
<31d65c78-5692-4817-b726-820c5df0801c>
This PR merges a feature branch developed by @spong and @andrew-goldstein , seeded by @jamesspi 's prototype of the assistant. Connectivity to LLMs is provided the [Generative AI Connector](<https://github.com/elastic/kibana/pull/157228>) , developed by @stephmilovic . This PR includes:
- A new reusable Kibana package containing the assistant: `x-pack/packages/kbn-elastic-assistant`
- See the `How to embed the Assistant in other parts of Kibana` for details
- Assistant integration into Elastic Security Solution workflows (e.g. alerts, cases, Timeline, rules, data quality)
### An assistant trained on the Elastic stack and Elastic Security
The [Generative AI Connector](<https://github.com/elastic/kibana/pull/157228>) connects the assistant to OpenAI and Azure OpenAI models trained with knowledge of the Elastic stack and the Elastic Security solution, including:
- The Elastic open [Detection Rules](https://github.com/elastic/detection-rules)
- The [Elastic Common Schema (ECS)](https://www.elastic.co/guide/en/ecs/current/index.html)
- Elastic query languages, including [KQL](https://www.elastic.co/guide/en/kibana/current/kuery-query.html), [EQL](https://www.elastic.co/guide/en/elasticsearch/reference/current/eql-syntax.html), and the [Elastic Query DSL](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html)
- [Elasticsearch API documentation](https://www.elastic.co/guide/en/elasticsearch/reference/8.8/rest-apis.html)
This training enables the assistant to offer fully interactive chat experiences that include:
- alert summarization
- interactive query generation
- workflow suggestions
- generating ingestion configurations that conform to the Elastic Common Schema
- your imagination
using context from Elastic Security.
### Take action from your conversations
The Actions (from assistant response):
- Send KQL to Timeline
- Send EQL to Timeline
- Send Elasticsearch DSL to Timeline
- Send Note to timeline
- Create new case
- Add to existing case
- Copy to clipboard
### Components architecture diagram
### How to embed the Assistant in other parts of Kibana
Follow the general instructions in `x-pack/packages/kbn-elastic-assistant/index.ts` to integrate the assistant into a Kibana app.
#### Step 1 - Wrap your Kibana app in the `AssistantProvider` component
```ts
// Step 1: Wrap your Kibana app in the `AssistantProvider` component. This typically
// happens in the root of your app. Optionally provide a custom title for the assistant:
/** provides context (from the app) to the assistant, and injects Kibana services, like `http` */
export { AssistantProvider } from './impl/assistant_context';
```
#### Step 2: Add the `AssistantOverlay` component to your app
```ts
// Step 2: Add the `AssistantOverlay` component to your app. This component displays the assistant
// overlay in a modal, bound to a shortcut key:
/** modal overlay for Elastic Assistant conversations */
export { AssistantOverlay } from './impl/assistant/assistant_overlay';
// In addition to the `AssistantOverlay`, or as an alternative, you may use the `Assistant` component
// to display the assistant without the modal overlay:
/** this component renders the Assistant without the modal overlay to, for example, render it in a Timeline tab */
export { Assistant } from './impl/assistant';
```
#### Step 3: Wherever you want to bring context into the assistant, use the any combination of the following
```ts
// Step 3: Wherever you want to bring context into the assistant, use the any combination of the following
// components and hooks:
// - `NewChat` component
// - `NewChatById` component
// - `useAssistantOverlay` hook
/**
* `NewChat` displays a _New chat_ icon button, providing all the context
* necessary to start a new chat. You may optionally style the button icon,
* or override the default _New chat_ text with custom content, like `🪄✨`
*
* USE THIS WHEN: All the data necessary to start a new chat is available
* in the same part of the React tree as the _New chat_ button.
*/
export { NewChat } from './impl/new_chat';
/**
* `NewChatByID` displays a _New chat_ icon button by providing only the `promptContextId`
* of a context that was (already) registered by the `useAssistantOverlay` hook. You may
* optionally style the button icon, or override the default _New chat_ text with custom
* content, like {'🪄✨'}
*
* USE THIS WHEN: all the data necessary to start a new chat is NOT available
* in the same part of the React tree as the _New chat_ button. When paired
* with the `useAssistantOverlay` hook, this option enables context to be be
* registered where the data is available, and then the _New chat_ button can be displayed
* in another part of the tree.
*/
export { NewChatById } from './impl/new_chat_by_id';
/**
* `useAssistantOverlay` is a hook that registers context with the assistant overlay, and
* returns an optional `showAssistantOverlay` function to display the assistant overlay.
* As an alterative to using the `showAssistantOverlay` returned from this hook, you may
* use the `NewChatById` component and pass it the `promptContextId` returned by this hook.
*
* USE THIS WHEN: You want to register context in one part of the tree, and then show
* a _New chat_ button in another part of the tree without passing around the data, or when
* you want to build a custom `New chat` button with features not not provided by the
* `NewChat` component.
*/
export { useAssistantOverlay } from './impl/assistant/use_assistant_overlay';
```
Co-authored-by: Garrett Spong <garrett.spong@elastic.co>
Co-authored-by: Andrew Macri <andrew.macri@elastic.co>
[Documentation](https://docs.google.com/document/d/1Ms8d8d_fbTTRHlBroEAKGNMNk3jFFgOAkVDRhqLxAPQ/edit?pli=1#)
issue: https://github.com/elastic/kibana/issues/158810
## Summary
This PR is a cleanup to make [this
POC](https://github.com/elastic/kibana/pull/155420) production ready
- Serverless PLI features splitting in Security Solution, to allow/deny
access to configured functionalities, using the current Kibana RBAC
service.
- Create the Upselling service to display Serveless-specific prompts in
the application when features are not available
- Create a `SecurityRoutePageWrapper` component that wraps Pages and
displays the upsell when necessary.
- We will refactor the code base to use `SecurityRoutePageWrapper`
everywhere on another PR.
- Create an Upsell page and section for entity analytics
bd8db822-2f4b-4545-9da7-bedc07d93f90
### test:
Serverless: `yarn serverless-security`.
* To change the product line you have to update
`xpack.serverless.security.productLineIds` on
`config/serverless.security.yml`.
ESS: `yarn start`
### Glossary
* PLI - Product Line Item (`Alert Triage`, `Osquery`, `Cases` , ... )
* Product Line - The product that the user is subscribed to (Security
Essentials, Security Complete, ...)
* essSecurity - New plugin with code that only runs for ESS offer
(non-serverless).
* App Feature - A security solution feature or group of features that
can be disabled for a product line. It can be mapped to PLIs (`Alert
Triage`, `Osquery`, `Cases` , ... ).
* Capability - A string that when present represents that the user can
access a given feature. A capability could be of the type UI or API
(`read_cases`, `crud_cases`, ...).
### Current architecture
### New architecture
### How does it work?
Every serverless product line (endpointEssentials, cloud essentials) can
define which features are enabled:
69d0fc15f4/x-pack/plugins/serverless_security/common/pli/pli_config.ts (L12-L19)
For ESS (non-serverless) offer we enable all features by default.
69d0fc15f4/x-pack/plugins/ess_security/server/constants.ts (L10-L13)
A feature can define privileges:
69d0fc15f4/x-pack/plugins/security_solution/server/lib/app_features/security_kibana_features.ts (L177-L185)
When the feature is enabled the privileges get merged into the base
config and injected into kibana features.
69d0fc15f4/x-pack/plugins/security_solution/server/lib/app_features/app_features.ts (L61-L70)
### TODO
- [x] lazy load these components
- [x] Add unit test to:
- ~SecurityRoutePageWrapper
x-pack/plugins/security_solution/public/common/components/security_route_page_wrapper/index.tsx~
-
~x-pack/plugins/security_solution/public/common/hooks/use_upselling.ts~
-
~x-pack/plugins/security_solution/public/common/lib/capabilities/has_capabilities.ts~
-
~x-pack/plugins/security_solution/public/common/lib/upsellings/upselling_service.ts~
- ~x-pack/plugins/serverless_security/common/pli/pli_features.ts~
-
~x-pack/plugins/serverless_security/public/components/upselling/register_upsellings.tsx~
-
~x-pack/plugins/security_solution/server/lib/app_features/app_features.ts~
### Checklist
Delete any items that are not applicable to this PR.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Creates Package `@kbn/ml-data-frame-analytics-utils` via `node
scripts/generate package @kbn/ml-data-frame-analytics-utils --web --dir
./x-pack/packages/ml/data_frame_analytics_utils`.
Moves some of the constants, types and utilities for Data Frame
Analytics to its own package. This is in preparation to move our data
grid related code to a package too. Since this code for now is only used
by our team I didn't do any renaming related to for example consistent
prefixing, this should be revisited in a follow up. Another opportunity
for a follow up might be a clean up of the types and check which ones
can be replaced by types from `estypes`.
- Closes https://github.com/elastic/kibana/issues/147885
- Closes https://github.com/elastic/kibana/issues/157109
## Summary
**Before:**
Unified Field List plugin has internal routes (wrappers for client code)
which exist only to run api functional tests against them:
- `/api/unified_field_list/existing_fields/{dataViewId}`
- `/api/unified_field_list/field_stats`
Client code does not call these routes directly. So there is no reason
in keeping and versioning them.
**After:**
- Internal routes are removed
- A new "Unified Field List Examples" page was created
http://localhost:5601/app/unifiedFieldListExamples
- API functional tests (which used the routes) were converted to
functional tests against this new example page
- Created a new `unifiedFieldList` page object which is used now in
functional tests (methods are extracted from existing `discover` page
object).
**For testing:**
Steps:
1. Run Kibana with examples: `yarn start --run-examples`
2. Install sample data
3. And navigate to Developer Examples > Unified Field List Examples
page.
### 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>
Closes#156534
## Summary
This PR adds the alertDetailsUrl to the infra rules. The value of this
variable is a link to the `observability > alerts` page filtered for
this instance of alert.
Here is an example of this action variable:
|alertDetailsUrl as action variable|Result of action|
|---|---|
||
**Note**
- I will change this field to `kibana.alert.url` in another
[ticket](https://github.com/elastic/kibana/issues/158359)
## 🧪 How to test
- Ensure that `server.publicBaseUrl` is configured in kibana.dev.yml
- Create a metric threshold/inventory/logs rule and use the
`context.alertDetailsUrl` in action for this rule
- After an alert is triggered, open the link provided by alertDetailsUrl
and make sure that the alert is filtered correctly
- Check the time range, it should be set for 5 mins before the alert
start time
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Carlos Crespo <crespocarlos@users.noreply.github.com>
## Summary
With the release of Per User Dark Mode, code should no longer rely on
calling `uiSettings` to determine which theme Kibana is displayed with.
With theme settings now configurable from User Profiles and Adv.
Settings, the code that was calling uiSettings to determine the Kibana
theme will not take into account which theme is currently being
displayed.
Applies an appropriate EUI theme based on the profile settings. In
particular for the following components:
- Anomaly swim lane (Fixes#158155 )
- Job tree map view (Fixes
https://github.com/elastic/kibana/issues/158304)
- Charts-related theme settings, e.g. the Single Metric Viewer
## Summary
While elastic/appex-qa is in process to take ownership over FTR related
code, from elastic/kibana-operations it will be good to keep track on
any changes happening and participate in the review process.
## Summary
Closes https://github.com/elastic/kibana/issues/154330
This PR:
- Moves the editor from unified-search to a standalone package
- The editor has now a core ui settings dependency but is going to have
an expressions dependency too when merged with the ESQL branch
- Adds a new plugin (text-based-languages) which is used to pass the
dependencies on the package. The user can either use this plugin without
giving any dependencies or use the package with passing the dependecies
on the KibanaContextProvider.
- Adds storybook for the editor (I used the mdx stories as we did on the
random sampling package)
<img width="1668" alt="image"
src="763a3112-1ae5-49bb-81f3-acd02892e402">
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Updating codeowners to reflect new D&R team structure. All previous
platform and alerts area ownership is now under
@elastic/security-detection-engine
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/157219
On the client, `URLSearchParams.set` encodes strings. On the server,
`query` values are passed to the route decoded. Therefore, there is no
need for special encoding or decoding of requestBody, other then rison
encoding.
PR creates `getTileUrlParams` to standardize vector tile URL creation
across sources. `getTileUrlParams` is placed in a package so it can be
used in integration tests. This greatly increases the maintainability of
integration tests as it makes them ore readable and creates tileUrls
just like the client does to ensure testing is as close to the real
thing as possible.
PR also updates getTileUrl generation to only pick requestBody keys used
by vector tile routes to avoid sending unnecessary data to the server.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes#157189
This PR adds a metric threshold integration test. This is the first step
in adding more test coverage for observability rules.
**Steps during the test**
1. Generating fake host data by using a similar implementation as
https://github.com/elastic/high-cardinality-cluster
- Data is generated for the last 15 mins
- Implementation was simplified only to cover fake hosts and was
converted to typescript
2. Creating an action using an index connector
3. Creating a metric threshold rule containing step number 2 action
4. Checking the status of the rule to be active
5. Checking the triggered action to have the correct parameters
6. Checking the generated alert to have the correct information
7. Clean up
**How to run locally**
- Run server
```
node scripts/functional_tests_server --config x-pack/test/api_integration/apis/metrics_ui/config.ts
```
- Then run the test
```
node scripts/functional_tests__runner --include-pack/test/api_integration/apis/metrics_ui/cometric_threshold_rule.ts --config x-pack/test/api_integration/apis/metrics_ui/config.ts
```
**Reference**
I created https://github.com/elastic/integrations/issues/6168 to find a
better way to generate data and make sure that data matches what
metricbeats generates
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Updated the code owner entry for `x-pack/plugins/serverless_search` from
`@elastic/appex-sharedux` to `@elastic/enterprise-search-frontend`
The Enterprise Search team will be owning the development of the
serverless search solution and we will need to be the ones reviewing PRs
within the team.
## Summary
This was most likely a mistake during the migrating packages to jsonc,
`kibana-design` should be before the overrides so in PR's we would have
specific team members as reviewers. If none specified than
`kibana-design` would take over.
This is communicated with @elastic/kibana-design members.
