## Summary
Updated the Kibana collapsible nav Enterprise Search category to Search.
Updated the App Search & Workplace Search app navLinkStatuses to
`hidden` to remove them from the Kibana nav.
### Screenshots
<img width="270" alt="image"
src="1397e701-ca87-46f2-8c15-565bc3a9202c">
## Summary
Closes https://github.com/elastic/kibana/issues/157203
Closes https://github.com/elastic/kibana/issues/158051
Closes https://github.com/elastic/kibana/issues/158049
With the addition of Per User Dark Mode, components can no longer rely
on `uiSettings` as the source of truth for theme.
CodeEditor fields used to call `uiSettings` to determine if Dark Mode
was enabled, which had been provided in each callers Kibana React
Context.
The new source of truth for theme is the `CoreStart >
ThemeServiceStart`.
Currently, not all callers of CodeEditor provide the `theme` service in
their Kibana Context in a similar way and some callers don't provide it
at all.
This PR updates CodeEditor to get theme values from the Kibana Context
using a new `useKibanaTheme` react hook.
It also attempts audit the callers of CodeEditor to see if their Kibana
Context contains the theme service at the top level (Where I could add
theme to a caller's Context without major changes, I did. Some cases
will require CodeOwner guidance).
The new `useKibanaTheme` react hook will throw a TypeError if theme
isn't found in the top level of the Kibana Context, this will help with
testing as the component will not render. I will remove this after
testing so as not to introduce breaking changes.
## Testing
Please review files for which you are CODEOWNER.
I've attempted to tag all usages of `CodeEditor`/`CodeEditorFIeld` with
a TODO comment with one of the following scenarios:
1) a note where theme was provided already/where I made changes to
provide it in the appropriate context
2) I've asked for CODEOWNER guidance
For scenario 1, please pull and test that CodeEditor locally:
1. Enable Dark Mode from Edit User Profiles by clicking on the Profile
Icon on the top right, and updating your profile.
2. Navigate to the CodeEditors in the plugins you own. If they render
and display in Dark Mode - add a green check to the table below - and
you're done!
3. If it is not rendering, please help me figure out where the theme
service should be provided in the context.
For scenario 2, we will need to figure out where to make changes so your
context is providing theme. Some of the more complex usages may need to
addressed in separate issues.
## Tracking
| Team | Plugin | Theme in Context ? | Verified Working |
| - | - | - | - |
| apm-ui | apm | APM Storybook broken | ? |
| kibana-presentation | presentation_util | Yes. | Yes |
| response-ops | trigger_actions_ui | Yes | Yes |
| response-ops | stack_alerts | Yes | Yes |
| kibana-security | security | Yes | Yes |
| security-defend-workflows | osquery | Yes | Yes |
| kibana-app-services | examples/expression_explorer | Yes | Yes |
| ml-ui | transform | Yes | Yes |
| ml-ui | ml | Yes | Yes |
| uptime | synthetics | Yes | Yes |
| kibana-gis | maps | Yes | Yes |
| kibana-gis | file_upload | Yes | Yes |
| platform-deployment-management | watcher | Yes | [AG] Yes |
| platform-deployment-management | snapshot_restore | Yes | [AG] Yes |
| platform-deployment-management | runtime_fields | Yes | [AG] Yes |
| platform-deployment-management | painless_lab | Yes | [AG] Yes |
| platform-deployment-management | ingest_pipelines | Yes | [AG] Yes |
| platform-deployment-management | index_management | Yes | [AG] Yes |
| platform-deployment-management | grokdebugger | Yes | [AG] Yes |
| platform-deployment-management | es_ui_shared | Yes | [AG] Yes |
| fleet | fleet | Yes | Yes |
| enterprise-search-frontend | enterprise_search | Yes | [AG] Yes |
| kibana-cloud-security-posture | cloud-security-posture | Yes | yes |
| sec-cloudnative-integrations | cloud_defend | Yes | Yes |
| kibana-visualizations/kibana-data-discovery | data | Yes | Yes |
| kibana-visualizations | examples/testing_embedded_lens | Yes | Yes |
| kibana-visualizations | vis_types | Yes | Yes |
| kibana-visualizations | vis_default_editor | Yes | Yes |
| kibana-visualizations | unified_search | Yes | Yes |
| kibana-visualizations | packages/kbn-text-based-editor | Yes | Yes |
| kibana-visualizatons | lens | Yes | Yes|
| kibana-core | saved_objects_management | Yes | Yes |
| kibana-presentation | inspector | Yes | Yes |
| kibana-presentation | canvas | Yes | Yes |
| kibana-data-discovery | discover | Yes | Yes |
| kibana-data-discovery | data_view_management | Yes | Yes |
| kibana-data-discovery | data_view_field_editor | Yes | Yes |
| appex-sharedux | advanced_settings | Yes | Yes |
| enterprise-search-frontend | serverless_search | Yes | [AG] Yes |
| - | - | - | - |
## Unit tests
Currently, many tests are failing since they are probably not providing
`theme` in the context. Once CODEOWNERs have weighed in on CodeEditors
usages that require discussion, I will update the accompanying tests.
## Release note
- Fixes theming of CodeEditors
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Alison Goryachev <alisonmllr20@gmail.com>
Co-authored-by: Dima Arnautov <dmitrii.arnautov@elastic.co>
Co-authored-by: Dima Arnautov <arnautov.dima@gmail.com>
## Summary
Fixes two subtle visual drag and drop thingies:
1. When reordering, the styles should look slightly differently:
before:
b0f0d053-f6cc-414b-96cb-0b8ad892b613
after:
c52f8786-72e2-4ef3-a943-8050d7acf348
2. When picking up a dragging item, the whole dimension panel is jumping
very slightly because we add `border`:
before:
8efa71ec-d449-4dc9-8390-d4c33c62c1e0
after:
dbec7e64-5cb3-4b32-afcc-2c376cfda4a2
## Summary
When I created drag and drop for Lens, the API I went for was not the
most readable one. It was designed this way because I wanted to gain
some performance, but it was very hard to maintain the performance gain
with a lot of changes in the drag and drop area because all the pieces
of the code needed to memoized in a tricky way and it wasn't
communicated well.
In the end it works even without these tricks so I decided to simplify
it in this PR.
The main changes include:
1. Instead of multiple `useState` per parameter, we keep all the state
in reducer both for `ReorderProvider` and `RootDragDropProvider`. Thanks
to that we get multiple improvements:
2. The code in `DragDrop` component becomes more descriptive as we don't
run multiple state updates when user executes an action but one state
update describing what actually happens (eg. `dispatchDnd({type:
'selectDropTarget' ....})`. The internal logic of the update lives in
the reducer.
3. We don't have to pass `trackUiCounterEvents` as another prop to
`DragDrop` and run it wherever we need - instead we pass it as a
middleware to the context and run before dispatching (and it's very easy
to add more middlewares if we need extra integrations at some point!)
4. We also run a11y announcements as a middleware instead of inside
`DragDrop` component
5. The `ChildDragDropProvider` props look much cleaner:
before:
```
<ChildDragDropProvider
keyboardMode={keyboardModeState}
setKeyboardMode={setKeyboardModeState}
dragging={draggingState.dragging}
setA11yMessage={setA11yMessage}
setDragging={setDragging}
activeDropTarget={activeDropTargetState}
setActiveDropTarget={setActiveDropTarget}
registerDropTarget={registerDropTarget}
dropTargetsByOrder={dropTargetsByOrderState}
dataTestSubjPrefix={dataTestSubj}
onTrackUICounterEvent={onTrackUICounterEvent}
>
{children}
</ChildDragDropProvider>
```
after:
```
<ChildDragDropProvider value={[state, dispatch]}>{children}</ChildDragDropProvider>
```
6. Created custom hook `useDragDropContext` instead of using
`useContext(DragContext)` and making DragContext private. This way we
will avoid potential problems with using context outside of root.
7. Bonus thing - if we ever decide to move to redux, the structure is
there already
What I am still not happy with is that the tests are very
domain-dependant instead of user-driven - instead of checking the store
actions, I should check the interface from the user perspective. I will
try to work on it once I find some time between more important tasks
though.
## Summary
Running FTR tests locally (not on CI) that make API requests to public
versioned Kibana endpoints is currently broken. This is because:
* we require version headers to be set for both internal and **public**
endpoints in **dev** by way of a runtime check (ensures our code is
locked to a version)
* the vast majority of FTR tests do not set these headers for talking to
public endpoints
* on CI, this is different as we run these tests against a distributable
build (i.e., non-dev)
This manifests locally as a 400 response. E.g. the current
api_integration tests for data views by running:
```
node scripts/functional_test_runner.js --config ./test/api_integration/config.js --grep 'index_pattern_crud'
```
---
There are a few ways to resolve this, this PR proposes that we:
* Keep FTR tests as they are (i.e., don't update all of them to set
headers when making requests to public versioned endpoints), this is a
useful way to exercise our intended end-user behaviour
* Make the version resolution behaviour not depend on `--dev`: rather
set the default resolution to `none` (new setting) when we run in
`--dev` so that it can be configured to behave as we want for tests.
In this way we keep the runtime check for its intended purpose and can
run our FTR tests "as end users" of our endpoints.
---
Close https://github.com/elastic/kibana/issues/161435
## Summary
Fix a bug that was causing the cluster to fall into an unrecoverable
state if an error occurs during the document migration phase of a `v2`
to `zdt` migration (first zdt migration to take over the `v2`
algorithm).
When an error occurs during the document migration phase, the index gets
in a state where `mappingVersions` is present but not `docVersions`, and
the algorithm wasn't able to understand what this state was, and
considered it to just be a plain `zdt` predecessors, which caused an
error when entering the document migration phase, as `docVersions`
couldn't be found.
This PR addresses this, by properly identifying this specific state, and
acting accordingly (by initiating a document migration without checking
for the versions in `docVersions`, as we do then coming from a plain v2
algo)
## Summary
This PR fixes few issues occurring while running FTR API tests against
actual serverless project.
How to run:
```
TEST_CLOUD=1 ES_SECURITY_ENABLED=1 NODE_TLS_REJECT_UNAUTHORIZED=0 TEST_ES_URL=<your_es_url_with_credentials> TEST_KIBANA_URL=<your_es_url_with_credentials> node --no-warnings scripts/functional_test_runner --es-version=8.9.0 --config x-pack/test_serverless/api_integration/test_suites/search/config.ts --bail
```
The first error is faced during Elasticsearch version validation
```
ERROR Error: attempted to use the "es" service to fetch Elasticsearch version info but the request failed: ResponseError: {"ok":false,"message":"Unknown resource."}
at SniffingTransport.request (/Users/dmle/github/kibana/node_modules/@elastic/transport/src/Transport.ts:535:17)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at Client.InfoApi [as info] (/Users/dmle/github/kibana/node_modules/@elastic/elasticsearch/src/api/api/info.ts:60:10)
at FunctionalTestRunner.validateEsVersion (functional_test_runner.ts:129:16)
at functional_test_runner.ts:64:11
at FunctionalTestRunner.runHarness (functional_test_runner.ts:251:14)
at FunctionalTestRunner.run (functional_test_runner.ts:48:12)
at log.defaultLevel (cli.ts:112:32)
at run.ts:70:7
at withProcRunner (with_proc_runner.ts:29:5)
at run (run.ts:69:5)
at FunctionalTestRunner.validateEsVersion (functional_test_runner.ts:131:13)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at functional_test_runner.ts:64:11
at FunctionalTestRunner.runHarness (functional_test_runner.ts:251:14)
at FunctionalTestRunner.run (functional_test_runner.ts:48:12)
at log.defaultLevel (cli.ts:112:32)
at run.ts:70:7
at withProcRunner (with_proc_runner.ts:29:5)
at run (run.ts:69:5)
```
Since there is no version term in case of serverless, we can skip
version check by using newly added to FTR schema `serverless` property
(`false` by default). It is set to `true` in root FTR config
`/shared/config.base`.
The next error is related to ESArchiver relying on `ES` FTR service to
provide ESClient.
```
ResponseError: security_exception
│ Root causes:
│ security_exception: unable to authenticate user [system_indices_superuser] for REST request [/kibana_sample_data_flights]
```
It is fixed by using the default user (from host url) instead of
`system_indices_superuser` we use in stateful run.
## Summary
This PR removes `onClose` prop from the expandable flyout as it is not
necessary anymore
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related to https://github.com/elastic/kibana/issues/150296
- Add the following SO model version change types:
- `data_removal`
- `unsafe_transform`
- Change the existing `data_backfill` type to something less permissive
- Update the tsdoc and documentation accordingly
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Addresses root cause of https://github.com/elastic/kibana/issues/158918
Underlying cause is that _esArchiver_ is messing up with the SO indices
whilst Kibana is already running.
This can cause some asynchronous calls made by Kibana (e.g. `GET
/.kibana_8.8.0/telemetry:telemetry`) to hit ES at the exact time where
the underlying SO indices are **just** recreated, causing the error
described in the related issue.
The idea of the fix is to delete `mappings.json`, used by _esArchiver_
to create the SO indices. This way, _esArchiver_ will use existing SO
indices instead (aka the "official" ones, created by Kibana at startup),
thus avoiding the problem altogether.
As a side effect:
- Documents in `data.json` must be updated so that they are correctly
inserted.
- The different FTR tests must make sure the SO indices are empty before
inserting those documents (done in the `before(), beforeEach()`
statements).
## Summary
Closes https://github.com/elastic/kibana/issues/160052
This PR adds support for the header banner in serverless projects.
<img width="1437" alt="image"
src="c950bbe7-46bb-4b82-b9ee-406aef7748dc">
**NOTE:** This PR adds support for the header banner by applying the
same techniques as in the "classic" layout: special class names of
`header__bar`/`header_firstBar`/`header__secondBar`. The effect is the
"header action menu" bar, which is an optional 2nd bar in the chrome
header, works better after this change when it is always visible. This
is a temporary issue that unblocks the header banner, and fixes other
overlapping issues with the current project layout stylings.
_As followup work_, the @elastic/appex-sharedux team will investigate
converting the Kibana page template to the new
[EuiPageTemplate](https://elastic.github.io/eui/#/templates/page-template/examples)
which supports horizontal sections of a page that have dynamic height --
we need this for the dynamic presence of the header banner, and the
intended dynamic presence of the header action menu.
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] 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))
- [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)
The `yarn es` command provides a useful `--use-cached` to avoid
redownloading the cache, but this is always skipped because no one set
the `exists` field is required by the command to check if the cache is
available.
This commit just adds that `exists` property where is needed (when reading
the `.meta` file) and leaves the rest of the code unaltered.
I could have implemented the same behavior by returning `null` from the
`readMeta` and doing a null check where we checked for the `exists`
property. Please feel free which approach you feel better.
- The new profiling items will be only visible when the profiling plugin
has been already installed. Otherwise, these are going to be hidden.
- The profiling plugin exposes three new Locators to facilitate the
navigation to the Flamegraph, TopN functions and Stacktraces pages.
- Add `new` badge property on the section component
<img width="486" alt="Screenshot 2023-06-14 at 1 55 09 PM"
src="6e353bfc-050c-4294-a4e4-fc46205d5d0e">
234863a4-0d99-4140-a5b5-702896b2c4a3
ee1635bd-5127-41d6-b434-4cee9b5ebe92
46ec9bb7-2cd0-43fc-9a1e-0d6eef70612f
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
We discover a bug in the apm-synthtrace tool when you run it against
systems with multiple user spaces. The change in code allows us to run
the tool without errors.
## Test locally
```bash
nvm install 16.20.1
nvm user 16.20.1
yarn kbn bootstrap
node scripts/synthtrace simple_trace.ts --target=https://${ELASTICSEARCH_USERNAME}:${ELASTICSEARCH_PASSWORD}@${ELASTICSEARCH_HOST} --live
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Close https://github.com/elastic/kibana/issues/160207.
Adds a new, additional mechanism for negotiating version (via query
parameter). This is specifically intended to enable Kibana versioned
endpoints to be usable in browser environments where setting a header is
not always possible (like in an `img` tag's `href`).
Note: the header-based version still takes precedence if present.
### 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
## Summary
This tiny PR ensures that widget contents are not rendered until
expanded (in the expandable flyout). This will
prevent unnecessary requests being sent when we open the flyout.
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
Fixes https://github.com/elastic/kibana/issues/160528
Follow up to https://github.com/elastic/kibana/pull/159241
This PR adds logic for query parameters to the new script generating
Console autocomplete definitions from ES specification. The logic is
explained in details in the
[file](https://github.com/elastic/kibana/pull/160515/files#diff-b6853462c38db4e237dbb3cdec9d9f6659aa3fdc5f96a6193f2c4bac1439db43)
but here is a short version:
- Currently, the autocomplete engine only works with url params of 2
types: boolean (`__flag__`) and a list of options (for example `['all',
'open', 'hidden']`). The script will convert all of the url params from
the specification into this format: a boolean or a list. If there are no
set options for a parameter, but a default value is known, then it will
be converted into a list with 1 option, for example `['random']` so that
the autocomplete engine will display it as a single suggestion. We also
need to convert any numbers to strings, because they won't be displayed
otherwise.
- Endpoints in the specification have a property `request` which in turn
has 2 properties describing url params: `attachedBehaviours` and
`query`. Both object contain an array of `property`'s each describing a
url param. `property` is configured with either a built in type
(`string`, `number`, `boolean`) or defined type, for example
`ExpandWildcards`. By finding the type `ExpandWildcards` in the
specification, we can convert this type to a list of options `['open',
'all', 'none', 'hidden']`.
### How to test
Similar to https://github.com/elastic/kibana/pull/159241, you need to
re-generenate the definitions and see if local changes to definitions
files make sense.
1. Checkout the ES specification
[repo](https://github.com/elastic/elasticsearch-specification)
2. Run the command `node scripts/generate_console_definitions.js
--source <ES_SPECIFICATION_REPO> --emptyDest`
3. Check the changes in the folder
`KIBANA_REPO/src/plugins/console/server/lib/spec_definitions/json/generated`
#### Intended changes to the definitions files
- Most of endpoints have 4 default url params that previously were not
in the definitions files but added to all endpoints in this
[file](https://github.com/elastic/kibana/blob/main/src/plugins/console/public/lib/autocomplete/url_params.js).
These params are configured in the interface `CommonQueryParameters` in
the specification (see this
[file](https://github.com/elastic/elasticsearch-specification/blob/main/specification/_spec_utils/behaviors.ts)).
<details>
The interface in the specification
```js
export interface CommonQueryParameters {
error_trace?: boolean
filter_path?: string | string[]
human?: boolean
pretty?: boolean
}
```
The converted url params
```json
"error_trace": "__flag__",
"filter_path": [],
"human": "__flag__",
"pretty": "__flag__",
```
</details>
- Previously existing `url_components` property in the definitions is
deleted and this change will be addressed separately. (not sure it is
currently working but added a task to the meta issue)
- Previously numbers were configured as `0` or `0.0` but that is not
currently displayed in suggestions. Instead, the new script converts
numbers to strings and if any default value is present, it will be
displayed as a suggestion.
---------
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>
issue https://github.com/elastic/kibana/issues/134442
## Summary
* Remove filter actions from the cases alerts page because it has no
search bar (as suggested by Sergi).
* Fix the `show_top_n` action not executing from inside a table cell
* Fix the `show_top_n` action not preselecting alerts on the cases
alerts table
Warning: `show_top_n` uses the global `timerange` but the cases page
doesn't have the time range picker.
closes [#157505](https://github.com/elastic/kibana/issues/157505)
fixes [#157740](https://github.com/elastic/kibana/issues/157740)
## Summary
This PR adds strict payload validation to `inventory_views` endpoint. I
tried to make the types consistent between sever and frontend code and
because of that more changes had to be made. I also refactored the
`toolbar_control` component, decoupling them from Inventory View and
Metrics Explorer View types
### How to test
- Call the endpoint below trying to use invalid values. see
[here](https://github.com/elastic/kibana/pull/160852/files#diff-058b21e249ebbe2795d450d07025d8904a58cfb07a97979e85975f87e931ffceR133-R143).
```bash
[POST|PUT] kbn:/api/infra/inventory_views
{
"attributes": {
"metric": {
"type": [TYPE]
},
"sort": {
"by": "name"
"direction": "desc"
},
"groupBy": [],
"nodeType": "host",
"view": "map",
"customOptions": [],
"customMetrics": [],
"boundsOverride": {
"max": 1,
"min": 0
},
"autoBounds": true,
"accountId": "",
"region": "",
"autoReload": false,
"filterQuery": {
"expression": "",
"kind": "kuery"
},
"legend": {
"palette": "cool",
"steps": 10,
"reverseColors": false
},
"timelineOpen": false,
"name": "test-uptime"
}
}
```
- Set up a local Kibana instance
- Navigate to `Infrastructure`
- In the UI, use the Saved View feature and try different field
combinations
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/156803
Use `apm.captureError` to properly capture errors thrown by the route
handler (as those errors are then converted to generic 500 errors before
being returned by the server to avoid leaking internal info)
## Summary
In a module where we'd copy configuration files, an `isFile` function
would give false positives on folders with `.` in their names (mistaking
them for extensions). It's now fixed to use `statSync(...).isFile()`.
Closes#161013
### Checklist
[x] Unit test added, and works
## 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>
- Adds function to ML plugin server side setup contract
(`setFeaturesEnabled`) to enable/disable features. Features being,
anomaly detection, data frame analytics or natural language processing.
- Each serverless plugin (search, observability and security) now calls
`setFeaturesEnabled` to enable different features on setup.
- Adds three new feature capabilities, `isADEnabled`, `isDFAEnabled`,
`isNLPEnabled`
- Updates the capabilities switcher to toggle these capabilities based
on the shared feature API. This currently has a bug where the switcher
isn't triggered for API tag checking.
- deeplinks are now only registered based on the feature capabilities,
these control what is shown in the nav menu for search and observability
projects.
- Adds the Machine Learning nav menu section to the `serverless_search`
plugin, to match the `serverless_observability` plugin.
- Does not updated the `serverless_security` plugin's nav menu. (update,
serverless_observability nav menu also now does not contain ML)
Relates to https://github.com/elastic/kibana/issues/160891
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Tackles the first improvement described in
https://github.com/elastic/kibana/issues/160038.
When "picking up" the updated mappings, we add a "query" in order to
select and update only the SO types that have been updated, compared to
the previous version.
We achieve this by comparing `migrationMappingPropertyHashes`; we
compare the hashes stored in the
`<soIndex>.mapping._meta.migrationMappingPropertyHashes` against the
ones calculated from the definitions from the `typeRegistry`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
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>
