Original issue: https://github.com/elastic/kibana/issues/144943
## Summary
* Update CellActions value to be `Serializable`.
* Update Default Actions and SecuritySolution Actions to allowlist the
supported Kibana types.
* Add an extra check to Action's `execute` to ensure the field value is
compatible.
### How to test it?
* Open Discover and create a saved search with many different field
types
* Go to Security Solutions dashboards
* Create a new dashboard and import the saved search
* Test the created dashboard inside Security Solutions
### 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/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
> **Note**
> For testing: enable the `agentTamperProtectionEnabled` feature flag.
This PR modifies the quite new `GET /api/fleet/uninstall_tokens` API:
- `GET /api/fleet/uninstall_tokens`, returns token 'metadata' (i.e.
**uninstall token id**, policy ID and creation date) for the latest
token for every policy, without the token itself.
- it is paginated (query params `page`, `perPage`),
- and can be searched by partial policy ID (query param `policyId`).
- this route is not used at the moment, will be used very soon
- `GET /api/fleet/uninstall_tokens/{id}` returns one decrypted token
identified by its ID
- ~`GET /api/fleet/agent_policies/{policyId}/uninstall_tokens`, returns
the decrypted token history for one policy~
- ~this route is used by the `UninstallCommandFlyout`~
- this was added and then removed, because not a necessity at the
moment, and let's keep open all doors for agent tampering v2
### Todo - done ✅
`created_at` field was removed from the uninstall token saved object
mapping (21855ce37b320e1864c5b9db647ac2355158f91d), because it was
unused and messed up ordering by the saved object's own `created_at`
field.
This removal is not allowed, though, so this issue needs to be fixed.
**Update:** after a discussion with Kibana Core team, the `created_at`
field was removed in a separate PR which is merged in v8.9.0. Reason:
it's okay to use the SO's internal `created_at` field for sorting. Also,
the mapping will be released in v8.9.0 first, so it's okay to modify it
this time. The PR: https://github.com/elastic/kibana/pull/159985
### 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: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/160173
## Summary
The rule registry lifecycle executor automatically sets the following
fields in alert docs:
- `event.action` - `open`, `active` or `close` depending on what type of
alert
- `event.kind` - always `signal`
- `tags` - merges rule tags with rule executor reported tags
- `kibana.version`
- `kibana.alert.workflow_status` - set to `open`
- `kibana.alert.time_range`
In addition, the rule registry lifecycle executor provides some helper
functions for the rule executors to get the alert UUID, the alert start
time (if it exists) and the alert document for recovered alerts (used to
set recovered context variables).
This PR augments the framework `AlertsClient` to set the same fields and
to provide the same functionality to the rule executors. When an alert
is reported via the `AlertsClient`, the UUID (either existing or newly
generated) and the start time (for ongoing alerts) is returned back to
the rule executors. When an executor requests the recovered alerts in
order to set context information, the existing alert document is
returned.
## To Verify
Check out [this
commit](dc5bebab1b)
which removes the metric threshold rule from the rule registry lifecycle
executor and onboards it to use the framework alerts client. Create a
metric threshold rule that creates active alerts and recovers alerts.
Inspect the alerts documents to make sure all the fields mentioned above
exist. Compare these documents with alerts created using the lifecycle
executor.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Closes#154081
In order to make it easier to test the Assets API signal source mode, we
wanted an easy way to generate test data for the signals we consume.
Since Synthtrace already produces test data for APM services and is
integrated with FTR, we felt it was a good path to try to extend it with
assets and infra data (which will benefit other teams as well in the
future).
This PR adds some barebones entities, and re-introduces the Monitoring
entities that had been removed in the past (hopefully this time in a way
that is unobtrusive).
In order to accommodate these new entities, this PR also extracts a base
client from the existing APM client, in order to share common code
between the new entity clients.
Tackles https://github.com/elastic/kibana/issues/158918
Updates `esArchiver` so that SO indices are created in two separate
steps:
`indices.create()` and `indices.updateAliases()`
This way, any Kibana requests that target SO indices (through their
aliases) will either find that the indices exist, or that they do not.
This is a less invasive approach than
https://github.com/elastic/kibana/pull/159397, as it does not modify the
`esArchiver.load` flow (we don't delete the `mappings.json` files here).
## 📓 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>
## Summary
This updates connector tiles for Enterprise Search to bring them in line
with 8.9.
<img width="1032" alt="Screenshot 2023-06-26 at 16 26 40"
src="a222a2a3-17ad-4e72-8ce8-57e09d89d05e">
<img width="1035" alt="Screenshot 2023-06-26 at 16 25 04"
src="3ce1e78c-b4fe-404b-b314-e02f3d6f439e">
<img width="1086" alt="Screenshot 2023-06-26 at 16 24 40"
src="14dd6ca5-875f-4c2d-9408-a2fa15abbbec">
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- close https://github.com/elastic/kibana/issues/156517
- built on top of https://github.com/elastic/kibana/pull/156855
- [Serverless chrome breadcrumbs
requirements](https://docs.google.com/document/d/1e5SbDPpySiPeBrjgLJD6Qw6fJyiy34uO2dmGLHlu38E/edit)
- [Serverless chrome breadcrumbs API tech
do](https://docs.google.com/document/d/1_qL14NMGYdI0913eclJd3DXG0lQ2jkE0V3578iaDASs/edit#heading=h.ndqge1i76y6p)
This PR implements serverless (project) breadcrumbs. Now Chrome
automatically renders the main part of the breadcrumbs based on the
project navigation tree and current active path. Plugins can append
their deeper context breadcrumbs or override the navigation breadcrumbs.
```
plugins.serverless.setBreadcrumbs(myDeeperContextBreadcrumbs);
plugins.serverless.setBreadcrumbs(myCustomBreadcrumbs, {absolute: true});
```
Oblt:
Search:
Security:
Security hasn't changed because they don't set the project navigation
tree yet. They still have regular breadcrumbs.
-----
Notes: We thought of a possible edge case where an app would set deeper
breadcrumbs `plugins.serverless.set breadcrumbs({text: 'foo', href:
'/foo'});` but the project navigation already have this link as part of
the path. If we hit this edge in the real world, we can workaround this
by merging the same consequent breadcrumbs by a deep link id.
---------
## Summary
Add support for `Boolean` and `Number` types to CellActions and update
Security Actions accordingly.
It also fixes the copy-to-clipboard action for fields of the type number
(`process.parent.pid`).
issue: https://github.com/elastic/kibana/issues/159298
- [x] Remove discover fields value casting if it gets merged after the
[discover PR](https://github.com/elastic/kibana/pull/157201)
### How to test it?
The quickest way is to find an alert field that is a boolean or number
on the alerts page and check if security solution actions still work.
But all boolean fields that I tested are actually strings. 🤷
Alternatively, you could render the `<SecurityCellActions />` with fake
data (boolean and number).
### 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: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Update doc links for search api and browser client doc link
---------
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>
## Summary
Adds the indexing API page as a plugin application and registers it's
deep link. This intentionally only implements the empty / no indices
state. Fetching indices and giving a combobox to select an index will be
done in another PR.
### Screenshots
<img width="1840" alt="image"
src="dc62c816-34b3-47be-ba24-e5e0a06d1533">
## Summary
Why?
To simplify the process of migration to react-router@6.
https://github.com/remix-run/react-router/discussions/8753
What problems exactly it solves?
- In my previous PR I added `CompatRouter`
https://github.com/elastic/kibana/pull/159173, which caused changes in
~50 files and pinged 15 Teams. And this is just meant to be a temporary
change, so when we're done with the migration I would have to revert
these changes and engage everyone to review the PR again. And it is just
a single step in the migration strategy. So to make our lives easier I
think it would be better to have a common place where we do import our
router components because it will allow us to surface some extra logic
in single place instead of going through the whole source code again.
- `react-router@6` doesn't support a custom `Route` component, so that
means our custom `Route` component that we're using almost everywhere
today, will need to be replaced by a different solution. I have decided
to add `Routes` component, which will be responsible for rendering the
proper component (`react-router@6` renamed `Switch` to `Routes`, so I
have named this component to align with the dictionary of the new
router) and also is going to add the logic that today is done in `Route`
(moving logic to `Routes` will be done in the follow-up PR, here I just
wanted to focus on using the common router components to make the review
process easier)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
closes: https://github.com/elastic/kibana/issues/157191
Enables Discover DataGrid to use registered cell actions instead of the
default static actions.
### New `cellActionsTriggerId` prop
This PR introduces a new `cellActionsTriggerId` _optional_ prop in the
DataGrid component:
98c210f9ec/src/plugins/discover/public/components/discover_grid/discover_grid.tsx (L198-L201)
When this prop is defined, the component queries the trigger's registry
to retrieve the cellActions attached to it, using the CellActions
package' `useDataGridColumnsCellActions` hook. This hook returns the
cellActions array ready to be passed for each column to the EuiDataGrid
component.
When (non-empty) actions are found in the registry, they are used,
replacing all of the default static Discover actions. Otherwise, the
default cell actions are used.
This new prop also allows other instances of the Discover DataGrid to be
configured with custom cell actions, which will probably be needed by
Security Timeline integration with Discover.
### New `SEARCH_EMBEDDABLE_CELL_ACTIONS_TRIGGER` Trigger
Along with the new `cellActionsTriggerId` prop the plugin also registers
a new trigger for "saved search" embeddable:
055750c8dd/src/plugins/discover/public/plugin.tsx (L387)
And it gets passed to the DataGrid component on the Embeddable creation:
055750c8dd/src/plugins/discover/public/embeddable/saved_search_embeddable.tsx (L403)
Having this new trigger available allows solutions to attach custom
actions to it, in order to be displayed in the saved search embeddables.
Each action will be able to implement its `isCompatible` check to
determine if they are going to be displayed in the embedded saved search
DataGrid field, or not. If no compatible actions are found, DataGrid
will render the default static actions.
ℹ️ In this implementation, the actions registered to this new
"embeddable trigger" need to check if they are being rendered inside
Security using the `isCompatible` function, to prevent them from being
displayed in other solutions, resulting in a non-optimal architecture.
This approach was needed since there's no plausible way to pass the
`cellActionsTriggerId` property from the Dashboard Renderer used in
Security, all the way down to the specific Discover "saved search"
embeddable. However, the Dashboards team is planning to enable us to
pass options to nested embeddables using a registry
(https://github.com/elastic/kibana/issues/148933). When this new tool is
available we will be able to delegate the trigger registering to
Security and configure the "saved search" embeddables to use it.
Therefore, the trigger will only be used by Security, so we won't have
to worry about Security actions being rendered outside Security.
## Videos
before:
de92cd74-6125-4766-8e9d-7e0985932618
after:
f9bd597a-860e-4572-aa9d-9f1c72c11a4b
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Pablo Neves Machado <pablo.nevesmachado@elastic.co>
- 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>
[](https://renovatebot.com)
This PR contains the following updates:
| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| [elastic-apm-node](https://togithub.com/elastic/apm-agent-nodejs) |
[`^3.46.0` ->
`^3.47.0`](https://renovatebot.com/diffs/npm/elastic-apm-node/3.46.0/3.47.0)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
---
### Release Notes
<details>
<summary>elastic/apm-agent-nodejs</summary>
###
[`v3.47.0`](https://togithub.com/elastic/apm-agent-nodejs/releases/tag/v3.47.0)
[Compare
Source](https://togithub.com/elastic/apm-agent-nodejs/compare/v3.46.0...v3.47.0)
For more information, please see the
[changelog](https://www.elastic.co/guide/en/apm/agent/nodejs/current/release-notes-3.x.html#release-notes-3.47.0).
##### Elastic APM Node.js agent layer ARNs
|Region|ARN|
|------|---|
|af-south-1|arn:aws:lambda:af-south-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-east-1|arn:aws:lambda:ap-east-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-northeast-1|arn:aws:lambda:ap-northeast-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-northeast-2|arn:aws:lambda:ap-northeast-2:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-northeast-3|arn:aws:lambda:ap-northeast-3:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-south-1|arn:aws:lambda:ap-south-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-southeast-1|arn:aws:lambda:ap-southeast-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-southeast-2|arn:aws:lambda:ap-southeast-2:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-southeast-3|arn:aws:lambda:ap-southeast-3:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ca-central-1|arn:aws:lambda:ca-central-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|eu-central-1|arn:aws:lambda:eu-central-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|eu-north-1|arn:aws:lambda:eu-north-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|eu-south-1|arn:aws:lambda:eu-south-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|eu-west-1|arn:aws:lambda:eu-west-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|eu-west-2|arn:aws:lambda:eu-west-2:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|eu-west-3|arn:aws:lambda:eu-west-3:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|me-south-1|arn:aws:lambda:me-south-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|sa-east-1|arn:aws:lambda:sa-east-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|us-east-1|arn:aws:lambda:us-east-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|us-east-2|arn:aws:lambda:us-east-2:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|us-west-1|arn:aws:lambda:us-west-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|us-west-2|arn:aws:lambda:us-west-2:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
</details>
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Mend
Renovate](https://www.mend.io/free-developer-tools/renovate/). View
repository job log
[here](https://developer.mend.io/github/elastic/kibana).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNS4xMzEuMCIsInVwZGF0ZWRJblZlciI6IjM1LjEzMS4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: pgayvallet <pierre.gayvallet@elastic.co>
issue: https://github.com/elastic/kibana/issues/150347
## Context
Some Actions need to access `FieldSpec` data, which is not present on
the `CellActions` API (`subType`and `isMapped`). So we are updating the
`CellActions` `field` property to be compatible with `FieldSpec`.
## Summary
This PR is the first step to fix
https://github.com/elastic/kibana/issues/150347.
* Updates the `CellActions` to support an array of data objects, each
containing field (`FieldSpec`) and value
* Create a new `SecurityCellActions` component that accepts a field name
and loads `FieldSpec` from the Dataview.
## Examples
Before:
```tsx
<SecurityCellActions
value={'admin'}
field={{
name: 'user.name',
type: 'keyword',
searchable: true,
aggregatable: true,
...
}} />
```
After:
```tsx
<SecurityCellActions data={{ field: 'user.name', value: 'admin' }}/>
```
`SecurityCellActions` will load the spec from the Dataview and provide
it to `CellActons`.
`CellActons` now also support an of fields instead of only one field. It
will be useful when rendering cell actions for aggregated data like on
the Entity Analytic page. But for now, the actions are not supporting
multiple values, we need to rewrite them
https://github.com/elastic/kibana/issues/159480.
### Next steps
We must refactor the Security Solution to get `FieldSpec` from the
`DataView` instead of using BrowserFields. Ideally, we have to do that
for every `CellAction` call so the actions can access the `subType`
property.
- [x] ~Refactor the Security Solution CellActions calls to get
`FieldSpec` from the `DataView`~
- [x] Refactor data grid cell actions to get `FieldSpec` from the
`DataView`
- [ ] Rewrite actions to support multiple fields and use them on the
investigation in timeline (.andFilters)
- [ ] Fix https://github.com/elastic/kibana/issues/150347 using
`subType` from `fieldSpec`
- [ ] Fix https://github.com/elastic/kibana/issues/154714 using
`isMapped` from `fieldSpec`
### Extra information
*** Previously we were mixing `esTypes` and `kbnTypes`. For example, if
the `esType` is a keyword the `kbnType` has to be a `string`.
[Here](9799dbba27/packages/kbn-field-types/src/types.ts (L22))
you can check all possible ES and KBN types and
[here](9799dbba27/packages/kbn-field-types/src/kbn_field_types_factory.ts)
you can see the mapping between esType and kbnType
### 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
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.
## Summary
Fixes https://github.com/elastic/kibana/issues/159572
1. The dimension element should be invisible when being moved - fixed by
`.domDragDrop-isHidden` css below `.domDragDrop--isDragStarted` that was
overwriting opacity.
before:
<img width="508" alt="Screenshot 2023-06-14 at 09 45 23"
src="96dcd98e-3b71-4675-8e0f-1617cfacbd2d">
after:
<img width="508" alt="Screenshot 2023-06-14 at 10 01 08"
src="f3b9de10-a2e5-4936-9695-245a57a9a8d4">
2. When navigating with keyboard, the margin of the element that was
moving was slightly off - fixed by changing the constant
`REORDER_ITEM_MARGIN` value to 16. Not sure if we use this package
somewhere else and I should also test @jughosta?
before:
<img width="436" alt="Screenshot 2023-06-14 at 09 45 38"
src="b6e3ad6e-fc6f-4c7f-850e-d3a4d8cf4775">
after:
<img width="405" alt="Screenshot 2023-06-14 at 10 01 16"
src="4b850ca2-64d2-4c2a-a313-a7c10434674a">
3. When navigating with keyboard but not reordering, the ghost element
was covering completely the element we would drop into. I fixed it by
changing the translation values. I think that's not expected? Or is this
intentional?
before:
<img width="410" alt="Screenshot 2023-06-14 at 09 45 47"
src="60296878-ca52-4d0c-bb49-5a84503d48ac">
after:
<img width="436" alt="Screenshot 2023-06-14 at 10 01 24"
src="c050fea1-10b2-4a72-95d3-fbfe920b9c96">
### Checklist
Delete any items that are not applicable to this PR.
- [ ] 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)
- [ ]
[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
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] 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 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))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### 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)
## Summary
Fixes https://github.com/elastic/kibana/issues/159540
Fixed by:
1. To fix the fill, I made the triangle and circle svgs consistent with
the ones from EUI. Now they work with fill and not with stroke. Thanks
to that we could remove `canFill` property.
2. To fix rotation for triangle, I added `!important` to transform when
adding `xyAnnotationIcon_rotate90`. Btw this class was added to path and
to svg, that's why before rotation was 45deg (because added to two
elements). I fixed it too.
<img width="804" alt="Screenshot 2023-06-13 at 10 13 27"
src="c52e2692-cbbf-4e22-9241-eab6a3aa7c6f">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR follows #159809 and adds content to the expandable accordion
sections. The 1st accorion (ELSER) is open by default on page visit.
We're also adding links in the sections, which point to documentation or
to internal Kibana pages (e.g. Behavioral Analytics, Trained Models).
New entries are being added to the doc links files.
### 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/packages/kbn-i18n/README.md)
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [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))
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Liam Thompson <32779855+leemthompo@users.noreply.github.com>
Closes#101920
This PR does three things:
- add a `terminate_after` parameter to the search request for the
scripted metric agg. This is a configurable setting
(`xpack.apm.serviceMapTerminateAfter`) and defaults to 100k. This is a
shard-level parameter, so there's still the possibility of lots of
shards individually returning 100k documents and the coordinating node
running out of memory because it is collecting all these docs from
individual shards. However, I suspect that there is already some
protection in the reduce phase that will terminate the request with a
stack_overflow_error without OOMing, I've reached out to the ES team to
confirm whether this is the case.
- add `xpack.apm.serviceMapMaxTraces`: this tells the max traces to
inspect in total, not just per search request. IE, if
`xpack.apm.serviceMapMaxTracesPerRequest` is 1, we simply chunk the
traces in n chunks, so it doesn't really help with memory management.
`serviceMapMaxTraces` refers to the total amount of traces to inspect.
- rewrite `getConnections` to use local mutation instead of
immutability. I saw huge CPU usage (with admittedly a pathological
scenario where there are 100s of services) in the `getConnections`
function, because it uses a deduplication mechanism that is O(n²), so I
rewrote it to O(n). Here's a before :
and after:
To reproduce an OOM, start ES with a much smaller amount of memory:
`$ ES_JAVA_OPTS='-Xms236m -Xmx236m' yarn es snapshot`
Then run the synthtrace Service Map OOM scenario:
`$ node scripts/synthtrace.js service_map_oom --from=now-15m --to=now
--clean`
Finally, navigate to `service-100` in the UI, and click on Service Map.
This should trigger an OOM.
## Summary
Disable the `Content extraction` in the pipelines flyout if the
connector has been configured to use local content extraction. This is
only applicable to SharePoint Online in 8.9.
## Summary
`created_at` field was added to the mapping for the uninstall token
Saved Object, but it's not used and causes trouble.
~There is a discussion whether to remove it from the mapping or not,
before the recently added mapping itself is released with v8.9.0, so I
prepared this PR to merge in case we want to remove it.~ The discussion
ended with the decision to remove the field, so the aim is to merge this
PR.
## Summary
Part of https://github.com/elastic/kibana/issues/149249
Add a new EBT context providing the page_title field to events.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/149249
Add a new EBT context providing the `page_url` field to events.
`page_url` is based on the current url's `pathname` and `hash`
exclusively (no domain, port, query param...)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
