## Summary
While working to extract various portions of the `advancedSettings`
plugin into packages, I found the `ComponentRegistry` in the plugin to
have a number of issues that contributed to a fairly bad UX:
- the API allows for adding/overriding the title, subtitle and footer of
the Advanced Settings page, but only the footer is rendered.
- the API is available to all plugins, but only renders a single
entry... so depending on the plugin load order, the render is not
guaranteed.
- filtering the footer in or out of the display is delegated to the
component itself, so:
- it only takes effect on render.
- the count is only updated if you click on the page that contains it,
but that logic is currently broken.
- the error message is inaccurate.
This PR fixes those issues and more:
- extracts the registry into its own package.
- changes the API to allow for multiple sections from multiple plugins.
- changes the API to filter these sections from the plugin, rather than
from each individual component.
- fixes state management to show sections, keep counts accurate, etc.
---------
Co-authored-by: Vadim Kibana <82822460+vadimkibana@users.noreply.github.com>
**Resolves: https://github.com/elastic/security-team/issues/7134**
## Summary
Implemented request and response schema generation from OpenAPI
specifications.
The code generator script scans the
`x-pack/plugins/security_solution/common/api` directory, locates all
`*.schema.yaml` files, and generates a corresponding `*.gen.ts` artifact
for each, containing `zod` schema definitions.
<hr/>
Right now, all generation sources are set to `x-codegen-enabled: false`
to prevent the creation of duplicate schemas. Maintaining the old
`io-ts` schemas alongside the new `zod` ones could potentially lead to
confusion among developers. Thus, the recommended migration strategy is
to incrementally replace old schema usages with new ones, subsequently
removing outdated ones. I'll be implementing this approach in the
upcoming PRs.
### How to use the generator
If you need to test the generator locally, enable several sources and
run the generator script to see the results.
Navigate to `x-pack/plugins/security_solution` and run `yarn
openapi:generate`
<img width="916" alt="image"
src="be1a8a61-b9ed-4359-bc3e-bf393f256859">
Important note: if you want to enable route schemas, ensure you also
enable all their dependencies, such as common schemas. Failing to do so
will result in the generated code importing non-existent files.
### Example
Input file
(`x-pack/plugins/security_solution/common/api/detection_engine/model/error_schema.schema.yaml`):
```yaml
openapi: 3.0.0
info:
title: Error Schema
version: 'not applicable'
paths: {}
components:
schemas:
ErrorSchema:
type: object
required:
- error
properties:
id:
type: string
rule_id:
$ref: './rule_schema/common_attributes.schema.yaml#/components/schemas/RuleSignatureId'
list_id:
type: string
minLength: 1
item_id:
type: string
minLength: 1
error:
type: object
required:
- status_code
- message
properties:
status_code:
type: integer
minimum: 400
message:
type: string
```
Generated output file
(`x-pack/plugins/security_solution/common/api/detection_engine/model/error_schema.gen.ts`):
```ts
/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
* or more contributor license agreements. Licensed under the Elastic License
* 2.0; you may not use this file except in compliance with the Elastic License
* 2.0.
*/
import { z } from 'zod';
/*
* NOTICE: Do not edit this file manually.
* This file is automatically generated by the OpenAPI Generator `yarn openapi:generate`.
*/
import { RuleSignatureId } from './rule_schema/common_attributes.gen';
export type ErrorSchema = z.infer<typeof ErrorSchema>;
export const ErrorSchema = z.object({
id: z.string().optional(),
rule_id: RuleSignatureId.optional(),
list_id: z.string().min(1).optional(),
item_id: z.string().min(1).optional(),
error: z.object({
status_code: z.number().min(400),
message: z.string(),
}),
});
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
closes [#163491](https://github.com/elastic/kibana/issues/163491)
## Summary
This PR creates a new package that contains a utility API that helps to
generate the JSON with the attributes required to render a Lens chart
with the `EmbeddableComponent`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This closes https://github.com/elastic/kibana/issues/161960, a basic
integration will now be created whilst onboarding logs (though the
custom logs flow).
This implements the *initial* version of this work, and does not include
things like adding a dataset to an existing integration.
## UI / UX
General:
Naming conflict errors:
Lack of permissions error:
General errors:
Success callout on the next panel:
Delete previous flow (happens in the background):
## Pointers for reviewers / next steps
- This PR also creates a new package for the `useTrackedPromise` hook,
as this is used in several places and I didn't want to just duplicate it
again (I haven't replaced other current uses in this PR, but will as a
followup).
- `useFetcher` was avoided as A) it's very tightly coupled with the
observability onboarding server route repository (and `callApi` is
scoped to this) and I wanted to call an "external" API in Fleet and B) I
wanted explicit control over when the request is dispatched (not on
mount), and whilst this can sort of be achieved by not returning a
promise from the callback it gets quite messy. I also wanted more
granular error handling control.
- Moving forward I think we'll need to enhance the state management of
the plugin. We'll want to add the ability to "add to existing
integration" and this is going to make the state more complex (even with
chunks of this functionality likely moved to it's own package). I did
actually have the Wizard state moved in to a constate container at one
point (as a starter) but I reverted this commit to make the changeset
less intrusive. It's for this same reason that, for now, I haven't
focussed too closely on extracting things like generating the friendly
error messages etc as we'll likely want to extract some of the "create
integration" hooks / UI in to a standalone package so they can be used
elsewhere (not just onboarding). There are also quite a few `
eslint-disable-next-line react-hooks/exhaustive-deps` rules in the
plugin at the moment due to the references not being stable, we could
improve that at the same time as any state changes.
- You can technically navigate directly to
`/fox/app/observabilityOnboarding/customLogs/installElasticAgent`, but
no state is stored in the URL, so nothing is rehydrated resulting in a
very empty configuration. I'm not entirely sure this is a behaviour we
want, but for now I've just made the callout conditional on state
existing (so coming from the previous panel).
- The Fleet custom integrations API now throws a 409 (conflict) when
using a name that already exists.
## Testing
- Head to `/app/observabilityOnboarding` to trigger the onboarding flow
- Select "Stream log files"
- When hitting "continue" an integration should be created in the
background (check the network requests for
`api/fleet/epm/custom_integrations`)
- When continuing (to install shipper), then going back **and** making
changes to your integration options, when clicking continue again there
should be a network request that deletes the previously created
integration (to clean things up). This should be seamless to the user.
- You should not be able to use a name that already exists (for an
existing custom integration)
- General errors (like permission issues, asset installation issues)
should display at the bottom
- When you hit the next panel (install shipper) there should be a
success callout that also contains the name of the integration that was
created
## In progress
~Two changes still in progress, but they don't need to hold up the
review (8.10 coming soon 👀):~
- ~To have a friendlier error for permissions issues (not just
"forbidden")~
- ~Fleet API integration test for the naming collision~
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
- Closes https://github.com/elastic/kibana/issues/155216
## Summary
This PR replaces shard falures toasts with inline warnings in Discover.
- [x] Intercept shard failures in Discover main app
- [x] Show inline warnings above the grid instead
- [x] Handle NoResultsFound case too
- [x] Implement for Discover context app
- [x] Implement for saved search embeddable on Dashboard
- [x] Can we inline timeouts too?
- [x] Check SQL view
- [x] Add tests
Discover view with shard failures
<img width="400" alt="Screenshot 2023-07-06 at 14 23 48"
src="a0799aa0-9d2e-42ee-b89b-e0e1180220a5">
Discover view with shard failures (and no results)
<img width="400" alt="Screenshot 2023-07-07 at 13 24 50"
src="28dc2bad-9776-4aa9-8f51-219d1c87487a">
Dashboard view with shard failures
<img width="400" alt="Screenshot 2023-07-06 at 16 15 49"
src="2a68c19a-1ca8-4f10-a9f5-4aa56f9160b0">
Surrounding documents view with shard failures
<img width="400" alt="Screenshot 2023-07-10 at 17 26 31"
src="ade63cfe-a1c2-4c22-8823-58dcfef9357f">
Discover view with timeouts
<img width="400" alt="Screenshot 2023-07-07 at 16 47 27"
src="0101be19-a555-4f96-b963-7fe418d51fb5">
Dashboard view with timeouts
<img width="400" alt="Screenshot 2023-07-07 at 16 48 18"
src="82979365-4129-4385-8a13-9c139e1acbf1">
Surrounding documents view with timeouts
<img width="400" alt="Screenshot 2023-07-11 at 15 03 41"
src="0ea41b79-ac6b-4456-9cfa-0d038b10da7d">
## Testing
For testing please uncomment
3f102cf688/src/plugins/data/common/search/search_source/search_source.ts (L922)
or
3f102cf688/src/plugins/data/common/search/search_source/search_source.ts (L547)
and switch to `kibana*` data view.
### Checklist
Delete any items that are not applicable to this PR.
- [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/packages/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
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
---------
Co-authored-by: Davis McPhee <davismcphee@hotmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Adds new connector type to support https://www.sentinelone.com/
The scope of this PR was limited to the Connector logic, schemas, and
types to make PR more digestible.
In the current PR, the connector is NOT registered, so it's not going to
be available to the users.
In the follow-up PR I'm going to improve the UX of Param's form and then
enable the connector
<img width="1685" alt="Zrzut ekranu 2023-08-3 o 11 18 54"
src="965ef8ef-497f-42a8-983e-38fd0370cba8">
visual changes include a screenshot or gif.
<img width="1685" alt="image"
src="119d2255-ed9f-4923-886d-eb139223a47d">
<img width="1690" alt="image"
src="e2c569d2-b497-4641-a6a6-454494223ffc">
## Summary
- Adds Endpoint Management and Policy Management to the base Security
Essentials Product Line Item in serverless
- Removes access to Endpoint policy protections (Malware, Ransomware,
etc) from the policy form when endpoint is being used without the
Endpoint Essentials/Complete addon
## Summary
Closes https://github.com/elastic/kibana/issues/162293 and partially
addresses [154601](https://github.com/elastic/kibana/issues/154601)
Removes the screenshot diagnostic tool but keeps the browser check
Removes PngV1ExportType from core and the export types registry
### Before
There were two steps so the EuiSteps component definitely made more
sense.
### After
I removed the use of the EuiSteps component since there's only the
browser check. Since the EuiSteps also showed some validation, I added a
callout to let users know the status of the diagnostic.
### Checklist
Delete any items that are not applicable to this PR.
- [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/packages/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>
## Summary
PR defines the set of available app features for serverless Product Line
Items (PLIs) for Endpoint addon. Changes include:
- Adds new Security Solution Serverless config file group:
`xpack.securitySolutionServerless.developer.*`. Used to facilitate
development. Values can be set via the
`config/serverless.security.dev.yml`
- Includes `disableManagementUrlRedirect` config option, which when set
to `true` will disable the redirect currently in place when a user
attempts to access the kibana Management pages.
- Defines the set of Kibana Privileges that goes along with Endpoint
Essentials and Endpoint Complete addons for serverless
- Includes cypress e2e tests for validating Endpoint Management related
access based on Product Tier (see below for list of test per role/per
product tier)
**Changes to e2e test framework:**
- Cypress `parallel` runner now normalizes the set of ENV variable
passed into each of the cypress runs
- Added support to Cypress for defining `productTier` via a Cypress test
file (`*.cy.ts`) top-level `describe(description, config, testFn)`
block. Will be applied when the stack is running in `serverless` mode.
- NOTE: if opening Cypress locally using `cypress:open`, you likely will
have to change the setup (only locally - don't commit) to only pickup
your 1 test file because the current implementation of Cypress
`parallel` only reads the first test file
- Serverless Security folder structure was altered with the following:
- `ftr` folder was created and all existing FTR tests moved under it (we
already had a `cypress` folder, thus those are clearly separated)
- a new folder was was created here `test_serverless/shared/lib`.
Contains code that should be test framework independent (aka: can be
used from both FTR and Cypress).
- It currently has the security solution role/user loader logic, thus it
can be used by both FTR (ex. API integration) and Cypress
### 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>
> Pre-req for https://github.com/elastic/kibana/issues/56406
## Summary
We've had a long-standing problem in Kibana around our use of React
context, particularly with EUI and i18n. There hasn't existed an
idempotent context structure, and that has lead to a lot of unexpected
results, (e.g. missing translations, inconsistent dark mode, excess
context providers, etc).
The biggest change coming from this PR is knowing exactly which provider
to use in a particular use case. This means, for example,
`ReactDOM.render` calls won't be missing `i18n` or `theme` due to a
missing context. It also allows consumers to use `darkMode` without
having to read the `uiSetting` themselves, instead allowing the context
to do it for them.
We also haven't been honoring the intended [`EuiProvider`
API](https://eui.elastic.co/#/utilities/provider#theming-and-global-styles)...
in some cases we've been creating and re-creating the Emotion caches,
often by copy/paste of the cache code. We've also been nesting
`EuiThemeProvider` contexts unnecessarily-- thinking we need to render a
theme provider in an isolated component-- which renders an additional
`span` element into the DOM.
This PR attempts to address this inconsistency by creating a set of
context providers divided by use case:
### `KibanaRootContextProvider`
A root context provider for Kibana. This is the top level context
provider that wraps the entire application. It is responsible for
initializing all of the other contexts and providing them to the
application. It's provided as a package for specific use cases, (e.g.
the `RenderingService`, cases where we replace the entire page content,
Storybook, testing, etc), but not intended for plugins.
### `KibanaRenderContextProvider`
A render context provider for Kibana. This context is designed to be
used with ad-hoc renders of React components, (usually with
`ReactDOM.render`).
### `KibanaThemeContextProvider`
A theme context provider for Kibana. A corollary to EUI's
`EuiThemeProvider`, it uses Kibana services to ensure the EUI Theme is
customized correctly.
### (deprecated) `KibanaStyledComponentsThemeProvider`
A styled components theme provider for Kibana. This package is supplied
for compatibility with legacy code, but should not be used in new code.
## Deprecation strategy
This PR does *not* change any use of context by consumers. It maps the
existing contexts in `kibanaReact` to the new contexts, (along with the
loose API). This means that we won't have completely fixed all of our
dark mode issues yet. But this is necessary to keep this PR focused on
the change, rather than drawing in a lot of teams to review individual
uses.
We should, however, see an immediate performance improvement in the UI
from the reduction in `EuiProvider` calls.
## Open questions
- [ ] Does it make sense to expose a `useTheme` hook from
`@kbn/react-kibana-context-theme` to replace `useEuiTheme`?
## Next steps
- [ ] Update deprecated uses to new contexts.
- [ ] Audit and update calls to `ReactDOM.render`.
- [ ] Add ESLint rule to warn for use of EUI contexts.
- [ ] Delete code from `kibanaReact`.
This PR makes the following changes:
- Update look & feel of contextual insights (previously called prompts)
according to the new design that is being developed. Some things might
still change, but hopefully not too much.
- Move all the Observability AI Assistant (previously called CoPilot)
code into a separate plugin for better isolation, more specific code
ownership and to solve some circular dependency issues
- Use connectors instead of a kibana.yml setting
Note: for OpenAI, the model is currently hardcoded to `gpt-4` until
https://github.com/elastic/kibana/issues/162204 has been addressed.
557676b6-065a-4b6f-86b2-1f0c2fd5e07e
---------
Co-authored-by: Coen Warmer <coen.warmer@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds `test/examples/discover_customization_examples` to the
`CODEOWNERS` file.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
- Originally Kibana's `http` service did not support receiving streams,
that's why we used plain `fetch` for this. This has been fixed in
#158678, so this PR updates the streaming helpers to use Kibana's `http`
service from now on.
- The PR also breaks out the response stream code into its own package
and restructures it to separate client and server side code. This brings
down the `aiops` bundle size by `~300KB`! 🥳
- The approach to client side throttling/buffering was also revamped:
There was an issue doing the throttling inside the generator function,
it always waited for the timeout. The buffering is now removed from
`fetchStream`, instead `useThrottle` from `react-use` is used on the
reduced `data` in `useFetchStream`. Loading log rate analysis results
got a lot snappier with this update!
## Summary
This PR enables the GitHub command /oblt-deploy-serverless. This command
allows Elasticians to deploy their PRs in a serverless environment with
Observability data.
### For maintainers
- [x] Requiere to merge
https://github.com/elastic/apm-pipeline-library/pull/2288
## Summary
Implementation of serverless-specific pages within the Unified IA
Navigation.
#### Links implemented:
- `Machine Learning`
- Landing page created on serverless only
- All links in the landing page go to `/ml` app
- `Dev Tools`
- Links directly to `/dev_tools` app
#### Links not implemented:
```// TODO: in a follow-up PR```
- Project Settings
- Change the _Settings_ name by _Project Settings_
- Modify the landing page items according to the design
## Changes
### Plugin contract changes
The Machine Learning landing page is the first page that is only available on serverless and should not exist in ess (there are more of this kind in the pipeline), so this PR implements the foundations to enable the _security_solution_serverless_ plugin to implement its own page components, configure the link definition and create new routes to render them in the Security Solution application.
These new APIs can be called from either `security_solution_serverless` or `security_solution_ess`, allowing those plugins to have their own offering-specific pages.
The new APIs exposed in the security_solution public contract are the following:
- `extraAppLinks$`: Observable to add extra app_links into the application links configuration, so they are stored and included in the SecuritySolution plugin `deepLinks` registry, to make them accessible from anywhere in the application using the `chrome.navLinks` API.
- `extraRoutes$`: Observable to add extra routes into the main Router, so it can render the new page components. These additional routes are appended after the "sub-plugin" (_alerts_, _timeline_, ...) routes, so it is not possible to override an existing route path.
### New `security-solution-navigation` package
Since now we need to use the same navigation components and hooks in different plugins, these functionalities have been extracted to the `@kbn/security-solution-navigation` package, which all Security plugins will depend on (generic, serverless, and ess).
The modules exposed by this package have been extracted from the main security_solution plugin and standardized. They include the Landing pages components (new [storybook](https://ci-artifacts.kibana.dev/storybooks/pr-161667/394abe76676c6a76b2982c1d3f5bb675739c3477/security_solution_packages/index.html?path=/story/landing-links-landing-links-icons-categories--landing-links-icons-categories) available), navigation hooks, and link utilities. Also, some types and constants have been moved to this package.
A new context provider has also been created, which needs to be in place in order to use this package. The `<NavigationProvider core={core}>` is required for the package functionalities to have access to the Kibana core navigation APIs: `navigateToUrl`, `navigateToApp`, and `getUrlForApp`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: YulNaumenko <jo.naumenko@gmail.com>
**Epic:** https://github.com/elastic/kibana/issues/153633
**Partially addresses:** https://github.com/elastic/kibana/issues/153645
## Summary
This PR builds upon https://github.com/elastic/kibana/pull/161900 and
moves tests located in the `e2e/detection_rules` folder into
`e2e/detection_response` and splits them into multiple sub-folders
according to the Detection Engine subdomains we have. It also updates
the CODEOWNERS file accordingly.
<img width="451" alt="Screenshot 2023-07-25 at 21 03 08"
src="fb6052c9-3c5d-4547-98f1-61f44b9f7187">
## Details
Specifically, changes in this PR include:
- The `e2e/detections_response` folder was renamed to
`e2e/detection_response`.
- The `e2e/detections_response/bulk_actions` folder became
`e2e/detection_response/rule_management/rule_actions/bulk_actions`.
- Cypress tests for rule types (which actually test rule creation for
different rule types) were moved to
`e2e/detection_response/rule_creation`.
- The CODEOWNERS file was updated.
Things not addressed in this PR:
- No ownership was assigned for `e2e/detection_response/rule_actions`.
Will need to figure this out with @yctercero.
- No restructuring was done for `security_solution/cypress/screens` and
`security_solution/cypress/tasks`. Will be done in follow-up PRs.
- No refactoring was done for the tests themselves. Some of this work is
also upcoming.
The full file structure of the `detection_response` tests looks like
this:
<img width="452" alt="Screenshot 2023-07-25 at 21 03 44"
src="2b89c6d2-9f2d-4cf6-914f-a71c3fa93595">
Moves the server and client side code which performs analysis on data to
see whether it is suitable for categorization.
This is currently only used by the categorization job wizard to display
this callout:
However this analysis will be useful for the Log Pattern Analysis
feature and so moving the code to a package allows easier sharing
between ML and AIOPs plugins.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Creates a shared package for Discover utils/services/hooks,
`@kbn/discover-utils`. Moves a couple of utils there
(`buildDataTableRecord`/`getDocId`). This will be the future home for
many services/utils that are shared between the Discover app and its
packaged components (like unified field list, unified histogram, etc.)
### Checklist
- [ ]
[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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
In support of https://github.com/elastic/security-team/issues/6726 -
defining a `common/api/` folder for types that must not have breaking
changes made to them.
security_solution/
| - common/
| | - api/
| | | - detection_engine/
| | | | - api_routes/
| | | | - model/
| | | | - sub_domains/
| | | | | - api_routes/
| | | - other_domains/
### Structure
- Every domain can have 3 components: sub-domains, a model, and api
routes
- Every API route has a folder dedicated to that route (e.g.
`/detection_engine/rule_management/crud/create_rule`)
- API route request and response schemas are defined in a single
`*_route.ts` file
- No file in `/common/api/` should import from outside of `/common/api`
(not implemented yet, but this will be enforced by the switch to OpenAPI
yaml files)
- Routes are grouped into domains for convenience
- Domains may have sub-domains
- Domains and sub-domains *may* contain a `model` folder for complex
structures that are shared throughout the domain (e.g.
`/detection_engine/model/rule_schema/`)
- `model` folders *must not* contain any routes in any sub-directory.
Any file with `/model/` in its path is a shared component, not a route.
- Every domain *must* contain at least one route
- Instead of creating `/detection_engine/rule_schema/model`, where
`rule_schema` would not have any routes, we should create
`/detection_engine/model/rule_schema`
- When importing API schemas from outside of `/common/api`, e.g. for
usage in `public` or `server` code, prefer importing from
`/common/api/<domain>` rather than `/common/api/<domain>/<sub
domain>/<route>` to avoid depending on the internal structure of the API
folder
- When importing from one API schema to another, prefer fully specifying
the import path (`/common/api/<domain>/<sub domain>/<route>` instead of
`/common/api/<domain>`) to avoid import cycle problems
- `index.ts` files should be created per top level API domain and export
the API schemas
- `index.ts` files may be created for sub domains if it's convenient
- Avoid importing schemas from one route into another - it's a sign that
the schema should be extracted to the common `model` for the domain
- There are still a number of places where this happens that I haven't
tried to fix yet
### Full List of APIs
https://docs.google.com/spreadsheets/d/1VCoJ74EkyGuj59VwWj_3v2ecB84pNCpzGqkYnS0SUKw/edit#gid=0
To print the full list of APIs for a plugin, add the following code in
`plugin.ts`:
```
const tempGet = router.get;
router.get = (route, handler) => {
console.log(`GET: ${route.path}`);
tempGet(route, handler);
};
const tempPost = router.post;
router.post = (route, handler) => {
console.log(`POST: ${route.path}`);
tempPost(route, handler);
};
const tempPut = router.put;
router.put = (route, handler) => {
console.log(`PUT: ${route.path}`);
tempPut(route, handler);
};
const tempPatch = router.patch;
router.patch = (route, handler) => {
console.log(`PATCH: ${route.path}`);
tempPatch(route, handler);
};
const tempDelete = router.delete;
router.delete = (route, handler) => {
console.log(`DELETE: ${route.path}`);
tempDelete(route, handler);
};
```
Resolves https://github.com/elastic/kibana/issues/159598
## Summary
This PR modifies the `test` subaction of the Generative AI connector to
accept a `stream` parameter (default: `false`) that allows for a
streaming response.
The Generative AI connector is basically a pass-through to the Open
AI/Azure OpenAI APIs, where the `stream` parameter is passed in via the
body of the request. This means that with the existing connector, users
could specify `stream: true` in the body which would lead to unexpected
results when the action is unprepared to return streaming results. This
PR sanitizes the body that is passed in the `run` subaction to prevent
the `stream` parameter from being set to `true` and explicitly sets the
`stream` parameter for the `test` subaction.
In order to test the streaming response, I created an example plugin
that prompts users to create a Generative AI connector if one does not
exist and then executes actions using the connector with `stream` set to
`true`. This borrows liberally from @dgieselaar's existing work from
https://github.com/elastic/kibana/pull/158678441694cb-0154-4450-bd93-3907c4a9995c
## To Verify
1. Navigate to https://localhost:5601/app/GenAiStreamingResponseExample
2. Set up a Generative AI connector
3. Open the network console. Enter a prompt and click `Stream Response`
4. You should see the chat response return streaming results.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Summary
This PR adds missing APM/Observability settings to the documentation:
- `observability:apmAgentExplorerView`
- `observability:apmAWSLambdaPriceFactor`
- `observability:apmAWSLambdaRequestCostPerMillion`
- `observability:apmEnableContinuousRollups`
- `observability:apmEnableServiceMetrics`
- `observability:apmLabsButton`
- `observability:apmServiceGroupMaxNumberOfServices`
- `observability:apmDefaultServiceEnvironment`
This PR also adds @elastic/obs-docs as a codeowner to
`/x-pack/plugins/observability/server/ui_settings.ts` so that we don't
miss documenting settings moving forward.
Closes https://github.com/elastic/kibana/issues/118795.
**Related to:** https://github.com/elastic/security-team/issues/6867
(internal)
## Summary
As requested in
https://github.com/elastic/kibana/pull/160685#issuecomment-1621635262.
In test plans, we mention how scenarios are going to be automated --
whether a given scenario will be automated using Cypress for e2e tests,
Jest for integration tests and unit tests, etc. But currently, test
plans are under `x-pack/plugins/security_solution/cypress/`.
Since test plans are in fact technology agnostic, it does not make much
sense to keep them inside a specific framework technology folder. That's
why we're moving them to a generic
`x-pack/plugins/security_solution/docs/testing` folder.
Fixes#155737. This passed 350 flaky test runner runs, reenabling. These API
integration tests were missing from CODEOWNERS, adding that in this PR
too (`/x-pack/test/api_integration/apis/aiops/ @elastic/ml-ui`).
## Risc score management page - Part I
For testing enable: `riskScoringRoutesEnabled`
This PR include:
- Entity analytics as a separate folder and lazy sub plugin - in the
future should include all entity analytics related frontend code
- Adding item to Security -> Manage page
- Layout for Entity Analytics management page
- Integrating with preview API
Not include:
- Integration with enable/disable risk score API
4499f3fb-ca19-46a8-8d4d-33fd7080738d
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
closes: https://github.com/elastic/kibana/issues/159685
- Renaming _x-pack/plugins_:
`serverless_security` -> `security_solution_serverless`
`ess_security` -> `security_solution_ess`
- All the related configurations and types have also been renamed.
- i18n translation prefixes updated
- relocation of internal `security_solution_serverless` directories to
be consistent with `security_solution_ess`
### Eslint
I also added the plugins in the `.eslintrc` configuration, defining the
same rules as the `security_solution` plugin.
All eslint errors have been addressed (mainly _type_ imports errors)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
Closes#159128
Due to a dependencies issue when disabling a plugin in serverless mode,
the LogStream feature and related logic were disabled for every
consumer.
We decided to split this shared component and endpoint into their own
plugin of shared logs utilities, reducing to the minimum the required
dependency that could disable the plugin.
What we moved can be summarized with:
- `infrastructure-monitoring-log-view` saved object definition and
registration
- LogViews server/client services (exposed with start contract) +
related endpoints
- LogEntries server service + related endpoints
- LogEntriesDomain logic (exposed with start contract)
- `<LogStream />` component
- `<ScrollableLogTextStreamView />` component and related logic
- LogView state machine
- Containers/Hooks to consume the moved APIs.
- Common types/utils definition, now exported and consumed as a
dependency from the `infra` plugin.
## 🤓 Review hints
Most of the changes are just renaming and moving stuff into the new
plugin, but for some operations was required to implement new logic,
which may deserve a more critical review:
- server/public `plugin.ts` files for the `infra` and `logs_shared`
plugins. The new plugin now registers the fallback actions to retrieve a
source configuration if there's no stored log view. It also set the
configuration for the message field and registers the log view saved
object.
- the `logEntriesDomain` has also been moved inside the new plugin, but
is also used by the logs-analysis endpoints, so it is exposed by the
logs_shared plugin and consumed by `infra`.
## 👣 Following steps
We currently are still using the `observability` plugin for consuming
the CoPilot feature on our LogsStream flyout.
The plugin dependency is marked as optional, so disabling the
`observability` plugin in a serverless environment won't disable also
the exposed features in this new plugin, but it'll affect only the
CoPilot feature, which won't be loaded.
In future, would be nice to extract the CoPilot feature into its own
package/plugin, so that also serverless projects can consume it without
depending on `observability.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes#152630
~Adds a fix for the weird UTC-but-not-really expected inputs in
rrule.js~
This PR removes the third-party `rrule` package and replaces it with
`@kbn/rrule`.
The third party RRule library's functions produced different results
depending on what system timezone you ran it in. It would output local
timestamps in UTC, making it impossible to do reliable math on them.
It's now replaced with our own library that passes all of our own tests
for the limited cross-section of the RRule spec that we need to support.
It's possible that it wouldn't stand up to the rigor of more complex
RRule queries, but it supports the ones that our Recurrence Scheduler UI
supports just fine.
### 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
Our original intent of kibanamachine approving their own PRs didn't
work, we switch to the default github-actions as an approver for
kibanamachine's PRs.
I believe I found out what was wrong with the previous implementation of
the action.
We were trying to check for the existence of the backport label when the
PR is created which is never there (as it gets added afterwards).
This PR is replacing the checking of the label by the assert that the
branch name on a backport starts with `backport` and the creator of the
PR is kibanamachine.
