Closes https://github.com/elastic/kibana/issues/45931
PR updates data plugin `search` and `bsearch` endpoints to return
method, path, and querystring request params from elasticsearch-js
client requests. This provides inspector with the exact details used to
fetch data from elasticsearch, ensuring inspector displays request
exactly as used by elasticsearch-js client.
**ESQL** This PR makes it possible to open ESQL searches in console.
<img width="500" alt="Screen Shot 2023-09-16 at 4 19 58 PM"
src="56019fb5-ca88-46cf-a42f-86f5f51edfcc">
### background
If you are thinking to yourself, "haven't I reviewed this before?", you
are right. This functionality has been through several iterations.
1) Original PR https://github.com/elastic/kibana/pull/166565 was
reverted for exposing `headers`.
2) [Fix to only expose method, path, and querystring keys from request
parameters](https://github.com/elastic/kibana/pull/167544) was rejected
because it applied changes to
`kibana_utils/server/report_server_error.ts`, which is used extensively
throughout Kibana.
3) This iteration moves logic into the data plugin to be as narrow as
possible.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix#170004
This PR fixes the wrong behaviour with message extraction from this type
of ES|QL responses.
Took also the opportunity to improve the FTR side, with some monaco
handlers for errors in the editor and some test cases for errors in
ES|QL queries.
### 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>
**Addresses:** https://github.com/elastic/kibana/issues/164451
## Summary
This PR allows to run role based reused between ESS and Serverless Cypress tests.
## Details
The main idea behind is to make environmental differences for tests unnoticeable. As Serverless env already has roles and users but ESS env allows to create any possible role and user we just need to create Serverless roles and corresponding users + specific ESS roles and corresponding users in ESS env before running any ESS tests. This way tests will run in a similar env and don't have to bother by roles/users creation in test suites. This is achieved by using separate Cypress support files (Cypress includes `support/e2e.js` by default) `ess_e2e.ts` and `serverless_e2e.ts` executed for corresponding environments. `ess_e2e.ts` contains logic to create mentioned above roles and users while `serverless_e2e.ts` doesn't contain such logic.
_Only one user created per role and user has the same name as its corresponding role with `changeme` password._
To have an ability to create roles we need to store their definitions somewhere. It's also convenient to have JSON definitions instead of YAML. Plus Serverless roles should be pulled from `project-controller` repo but it's not addressed in this PR. I've chosen the following locations
- Serverless Security roles in `packages/kbn-es/src/serverless_resources/security_roles.json`. While `@kbn/es` is a common package it has `serverless_resources` folder containing `roles.yml` with a mix of `https://github.com/elastic/project-controller/blob/main/internal/project/observability/config/roles.yml`, `https://github.com/elastic/project-controller/blob/main/internal/project/esproject/config/roles.yml` and `https://github.com/elastic/project-controller/blob/main/internal/project/security/config/roles.yml` copied from `project-controller` and used for ES data restore. As there is no automation yet it looks logical to keep Security roles subset next to ES Serverless resources.
- ESS Security specific roles in `x-pack/plugins/security_solution/common/test/ess_roles.json`
On top of that the following has been done
- `reader` role replaced with `t1_analyst` where possible in tests (besides `e2e/explore/cases/attach_alert_to_case.cy.ts` but it's purely ESS test so it's fine) as `reader` is ESS specific and make harder to run the same tests in ESS and Serverless environments but both roles are almost equivalent
- `login()` helper function accepts all known roles (Serverless + ESS) but throws an exception if a custom ESS role is used under Serverless env
- `x-pack/plugins/security_solution/server/lib/detection_engine/scripts/roles_users` isn't necessary anymore as `security_roles.json` + `ess_roles.json` contain all the necessary data to create roles and users
### Does it enable role support for MKI environments?
No. This PR only enabling role support for Non-MKI Serverless environments. MKI env has predefined roles but not users. This will be addressed in a follow up PR.
## Flaky test runner
Two unskiped in this PR Serverless Cypress tests using non default role `detection_response/detection_alerts/missing_privileges_callout.cy.ts` and `detection_response/prebuilt_rules/prebuilt_rules_install_update_authorization.cy.ts` [150 runs](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/3723) 🟢 (there is one env related failure but it doesn't look related to the changes in this PR)
Fix a flaky test caused by a layout shift that causes the false element to get a click. With the keyboard based approach this can be ruled out and on top of it, `pressEnter` of test subjects can be used in other cases, too. On top of that also the click based method for this action is improved, which is consumed by other parts of the functional test suites.
Closes https://github.com/elastic/kibana/issues/167906
PR breaks monolith component `<SearchResponseWarnings/>` into 3 separate
components: `<SearchResponseWarningsBadge/>`,
`<SearchResponseWarningsCallout/>`, and
`<SearchResponseWarningsEmptyPrompt/>`. These components are designed to
display a single messages when provided warnings from multiple requests
and display better messaging around partial results. PR also removes
`message` from `SearchResponseWarning` type.
Collaborated with @gchaps on copy.
### Test setup
1. install sample web logs data set
2. install sample flights data set
3. Create data view.
1. Set **Index pattern** to `kibana_sample_data*`
2. Set **Time field** to `timestamp`
4. Open discover
5. Select **kibana_sample_data*** data view
6. set time range to last 24 hours
7. Add filter
```
{
"error_query": {
"indices": [
{
"error_type": "exception",
"message": "shard failure message 123",
"name": "kibana_sample_data_logs",
"shard_ids": [
0
]
}
]
}
}
```
8) save search as **kibana_sample_data***
#### Search response warnings callout
1. Open saved search created in test setup
<img width="500" alt="Screenshot 2023-10-24 at 8 49 19 AM"
src="867cff58-c201-4a6b-b049-7136b43d053f">
2. Click "expand" icon on left of first row in documents table
3. Click "Surrounding documents"
4. Re-enable "kibana_sample_data_logs failure" filter
<img width="500" alt="Screenshot 2023-10-24 at 8 51 22 AM"
src="a50cf033-64de-4909-a47d-6ee07bb915ea">
#### Search response warnings empty prompt
1. Open saved search created in test setup
2. Add filter `DistanceKilometers is -1`
<img width="500" alt="Screenshot 2023-10-24 at 8 44 13 AM"
src="e3ae0fac-8bda-4cad-b079-8ace4e01b786">
#### Search response warnings badge
1. create new dashboard
2. add saved search created during test setup
<img width="500" alt="Screenshot 2023-10-26 at 9 15 21 AM"
src="0066e3e2-953b-4631-a7aa-f389f7e6dbfc">
#### Search response warnings toast
1. create new table aggregation visualization
2. Use saved search created during test setup as source
<img width="500" alt="Screenshot 2023-10-24 at 2 59 41 PM"
src="58aab97e-71d9-49d9-bd67-73484ec54751">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related to #161882
The goal is to prevent FTR tests from new esArchives that overrides SO
indexes.
This PR adds the existing archives that re-create Saved Objects indexes
into temporary exception list, located in
`packages/kbn-es-archiver/src/fixtures/override_saved_objects_index/exception_list.json`.
Whenever tests/archives are updated to not modify SO indexes, archive is
expected to be removed from the list (progress can be tracked in
#169075, #168973, #168969, #168926 )
Load action has a check if index is SO index and if the archive is in
the exception list. This will throw error for the new archives, but
still work as usual for the existing ones while teams updating the
tests.
Whenever test is loading archive listed in the exception list, the
following warning message is logged:
```
warn x-pack/test/functional/es_archives/data/search_sessions overrides Saved Objects index(es) and placed temporary in the exception list.
Please fix the archive and remove it from /Users/dmle/github/kibana/packages/kbn-es-archiver/src/fixtures/override_saved_objects_index/exception_list.json.
For more details see: https://github.com/elastic/kibana/issues/161882
```
If the test loads a newly added archive that modifies a Saved Object
index (e.g. `.kibana`), esArchiver will throw the error:
```
Error: esArchiver doesn't support modifying the existing Saved Objects index: '.kibana_1',
please update its definition in mappings.json
```
## Summary
This changes how serverless breadcrumbs are implemented in Discover. It
simplifies the current implementation and also fixes an issue with
"Discover" breadcrumb missing context from it's URL (see
https://github.com/elastic/kibana/pull/163607#pullrequestreview-1574271316)
Instead of using `serverless.setBreadcrums` API for deeper context
serverless breadcrumb, this PR adds `deepLinkId` to base discover
breadcrumb. Based on this id the navigational breadcrumbs are merged
with the regular breadcrumbs set in `chrome.setBreadcrumbs`). (This
feature was implemented here:
https://github.com/elastic/kibana/pull/169513)
This PR also improves "Discover" breadcrumb in oblt project when
navigated from logs explorer to discover by adding "discover" to the
navigation tree and hiding it from side nav.
Closes https://github.com/elastic/kibana/issues/169339
## Summary
* Hides the "Alerts and rule" dropdown in the Infra header behind a
feature flag in serverless
* Moves serverless infra tests to the `index.feature_flags.ts` to
prevent failures on MKI
## How to test
* Run in serverless
* Make sure the Alerts and rules dropdown is not there anymore
* Run in stateful
* Make sure dropdown works as before
### Summary
Fix https://github.com/elastic/kibana/issues/166688
Implements dynamic contract resolving for plugins, allowing to retrieve
contracts after their respective lifecycle is completed, and therefore
working around cyclic dependencies.
In term of workflow execution, we're basically going from
<img width="842" alt="Screenshot 2023-09-27 at 08 09 27"
src="251637d1-ec97-4071-a445-2f59512ce187">
to:
<img width="1092" alt="Screenshot 2023-09-27 at 08 09 32"
src="de466cda-7e43-4fd3-81ec-4339d05d279d">
### API
This functionality is exposed by the now publicly exposed `plugins`
service contracts:
```ts
setup(core) {
core.plugins.onSetup<{pluginA: SetupContractA, pluginB: SetupContractA}>('pluginA', 'pluginB')
.then(({ pluginA, pluginB }) => {
if(pluginA.found && pluginB.found) {
// do something with pluginA.contract and pluginB.contract
}
});
}
```
```ts
start(core) {
core.plugins.onStart<{pluginA: StartContractA, pluginB: StartContractA}>('pluginA', 'pluginB')
.then(({ pluginA, pluginB }) => {
if(pluginA.found && pluginB.found) {
// do something with pluginA.contract and pluginB.contract
}
});
}
```
**remark:** the `setup` contract exposed both `onSetup` and `onStart`,
while the `start` contract only exposed `onStart`. The intent is to
avoid fully disrupting the concept of lifecycle stages.
### Guardrails
To prevent developer from abusing this new API, or at least to add some
visibility on its adoption, plugins can only perforn dynamic contract
resolving against dependencies explicitly defined in their manifest:
- any required dependencies (*existing concept*)
- any optional dependencies (*existing concept*)
- any runtime dependencies (**new concept**)
Runtime dependencies must be specified using the new
`runtimePluginDependencies` field of a plugin's manifest.
```json
{
"type": "plugin",
"id": "@kbn/some-id",
"owner": "@elastic/kibana-core",
"plugin": {
"id": "some-id",
"...": "...",
"runtimePluginDependencies" : ["someOtherPluginId"]
}
}
```
Using the contract resolving API will throw at call time when trying to
resolve the contract for an undeclared dependency.
E.g this would throw at invocation time (not returning a rejected
promise - throw).
```ts
setup(core) {
core.plugins.onSetup<{undeclaredDependency: SomeContract}>('undeclaredDependency');
}
```
The reasoning behind throwing is that these errors should only occur
during the development process, and an hard fail is way more visible
than a promise rejection that should be more easily shallowed.
### Code reviews
This PR defines @elastic/kibana-core as codeowner of all `kibana.jsonc`
files in the `src/plugins` and `x-pack/plugins` directories, so that a
code review will be triggered whenever anyone changes something in any
manifest. The intent is to be able to monitor new usages of the feature,
via the addition of entries in the `runtimePluginDependencies` option of
the manifest.
### Remarks
Exposing this API, and therefore making possible cyclic dependencies
between plugins, opens the door to other questions.
For instance, cross-plugin type imports are not technically possible at
the moment, given that plugins are referencing each others via TS refs,
and refs forbid cyclic dependencies. Which means that to leverage this
to address cyclic dependency issues, the public types of **at least one
of the two** plugins will have to be extracted to a shared place (likely
a package).
Resolving, or trying to improve the developer experience around this
issue, is absolutely out of scope of the current PR (and the issue it
addresses).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes#167713 and #169276
## Summary
It appears the dashboard links were not ready (still loading) when the
test was trying to click on them. When they finish loading the element
was stale, triggering the StaleElement error. This PR calls the
RenderCompleteDispatcher on the Links embeddable when all of the child
components have finished loading.
In a future PR, we should consider re-factoring such that the async
dashboard fetching happens in the LinksComponent and the results are
passed as props to the DashboardLinkComponents. This would be more
React-like. I resisted making that change in this PR so that we can fix
the reporting error for v8.11.
## Flaky test runner 🤞https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/3636
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/167654
## Summary
This PR removes the Storage size column in Data stream in serverless as
the data stream stats API on serverless doesn't currently return the
storage size.
### How to test:
Verify that the column is not displayed in serverless:
1. Start Es with `yarn es serverless` and Kibana with `yarn
serverless-{es/oblt/security}`
2. Go to Stack Management -> Index Management -> Data Streams
3. Switch on the "Include stats" toggle
4. Verify that the "Storage size" column is not shown in the table.
Verify that the column is displayed in stateful:
1. Start Es with `yarn es snapshot` and Kibana with `yarn start`
2. Go to Stack Management -> Index Management -> Data Streams
3. Switch on the "Include stats" toggle
4. Verify that the "Storage size" column is shown in the table.
<!---
### 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)
-->
Closes https://github.com/elastic/kibana/issues/167099
#### Problem
`/bsearch` and `/search` APIs only return `error` key from elasticsearch
error response. This is problematic because Inspector needs
`rawResponse` to populate "Clusters and shards"
While working on this issue, I discovered another problem with how error
responses are added to inspector requestResponder. The `Error` instance
is added as `json` key. This is a little awkward since the response tab
just stringifies the contents of `json`, thus stringifing the Error
object instead of just the error body returned from API. This PR address
this problem by setting `json` to either `attributes` or `{ message }`.
#### Solution
PR updates `/bsearch` and `/search` APIs to return `{ attributes: {
error: ErrorCause, rawResponse }}` for failed responses. Solution
avoided changing KbnServerError and reportServerError since these
methods are used extensivly throughout Kibana (see
https://github.com/elastic/kibana/pull/167544#discussion_r1342460941 for
more details). Instead, KbnSearchError and reportSearchError are created
to report search error messages.
#### Test
1) install web logs sample data set
2) open discover
3) add filter
```
{
"error_query": {
"indices": [
{
"error_type": "exception",
"message": "local shard failure message 123",
"name": "kibana_sample_data_logs",
"shard_ids": [
0
]
}
]
}
}
```
4) Open inspector. Verify "Clusters and shards" tab is visible and
populated. Verify "Response" tab shows "error" and "rawResponse" keys.
<img width="500" alt="Screenshot 2023-10-09 at 9 29 16 AM"
src="461b0eb0-0502-4d48-a487-68025ef24d35">
<img width="500" alt="Screenshot 2023-10-09 at 9 29 06 AM"
src="9aff41eb-f771-48e3-a66d-1447689c2c6a">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Gloria Hornero <gloria.hornero@elastic.co>
Closes https://github.com/elastic/kibana/issues/167661
## Summary
After a whole bunch of investigation, I ultimately realized that the
attached test was flaky because the dashboard session storage was being
cleared in the `DashboardUnsavedListing` component. When loading the
unsaved dashboards, we used to remove the unsaved state for dashboards
that returned **any** error from the CM service - this was designed so
that, if a dashboard was deleted, we would remove it from the unsaved
dashboard listing callout. However, as an unintended consequence,
**other** errors, which should **not** cause the unsaved state to be
lost, also caused it to be cleared.
Since I could only replicate **some** of the possible CM errors locally,
it was impossible to narrow down exactly what error was being thrown in
the attached flaky test since the FTR does not provide console logs.
Therefore, rather than **preventing** that specific error from clearing
the session storage, I instead made it so that **only** `404` errors
(i.e. `"Saved object not found"` errors) cause the session storage to be
cleared - this will guarantee that we only remove the unsaved state from
the session storage if we know **for sure** that the dashboard has been
deleted. Any other errors that are thrown by the CM will **not** cause
the unsaved state to be unnecessarily lost.
Also, in my attempt to solve the above flaky test, I discovered and
fixed the following:
1. Previously, when an error was thrown and caught in the
`DashboardUnsavedListing` component, the `refreshUnsavedDashboards`
would cause a `useEffect` infinite loop because the reference for the
`unsavedDashboardIds` array would always be different even if the
contents of the array were identical. This PR fixes that by ensuring the
array reference **only** changes if the contents change.
2. Our previous way of catching errors in the `findDashboardById` method
was not reliable, and did not catch errors that were thrown in, for
example, the CM client `get` method. I refactored this so that all
errors should now be caught.
### [Flaky Test
Runner](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/3554)
### 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
### 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)
- Closes https://github.com/elastic/kibana/issues/168607
## Summary
This PR allows to search in DocViewer not only for partial matches but
also for wildcard matches.
<img width="400" alt="Screenshot 2023-10-11 at 16 51 36"
src="ec5dc57f-e540-48c6-b43c-d79d64ef1809">
<img width="400" alt="Screenshot 2023-10-11 at 16 51 48"
src="c68a3b70-c195-4da9-bb0c-12ca38db269c">
<img width="400" alt="Screenshot 2023-10-11 at 16 52 24"
src="d2d37976-559d-4cc3-852f-5ad3175808cc">
### 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
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
## Summary
Fixes https://github.com/elastic/kibana/issues/165895
This PR limits which index settings are displayed on the index details
page, "Settings" tab in the edit mode. On serverless only a handful of
index settings will be editable by the user. The UI only prevents
displaying some index settings, but it's still possible for the user to
type in a setting that can't be edited. That is the case on dedicated as
well.
### How to test
1. Start Serverless ES and Kibana
2. Navigate to Index Management and create a test index
3. Click on the index name and on the details page click the tab
"Settings"
4. Toggle the "Edit mode" switch and verify that only editable settings
are displayed.
#### Screenshot
<img width="527" alt="Screenshot 2023-10-16 at 20 25 49"
src="e6678cca-3494-4c63-ae66-ace9c823d12d">
## Summary
Closes https://github.com/elastic/ingest-dev/issues/2396
Added a new kibana task that publishes Agent metrics every minute to
data streams installed by fleet_server package.
Opened the pr for review, there are a few things to finalize, but the
core logic won't change much.
To test locally:
- Install fleet_server package 1.4.0 from
[this](https://github.com/elastic/integrations/pull/8145) pr to get the
mappings
- Start kibana locally, wait for a few minutes for the metrics task to
run (every minute)
- Go to discover, `metrics-*` index pattern, filter on
`data_stream.dataset: fleet_server.*`
- Expect data to be populated in `fleet_server.agent_status` and
`fleet_server.agent_versions` datasets.
<img width="1787" alt="image"
src="615af9df-fe4b-4c17-8c8c-88646c403a18">
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/162978
## Summary
This PR removes the `labs:dashboard:dashboardControls` advanced UI
setting. The removal of this setting is **not** a breaking change, as it
hasn't functioned properly for quite some time; it is completely safe to
remove this setting **regardless** of the previous value. Telemetry
tracking for this setting is also no longer required.
### 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
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Reverts elastic/kibana#168174
Reverting the previous PR - tests passed and the PR appeared to work
because ES is doesn't always enforce 'allowHidden' on hidden indices.
## Summary
Previously, the 'Allow hidden and system indices' advanced option when
creating a data view was only a UI convenience. It allowed you to see
which hidden and system indices you were matching but they would be
would be selected just the same once the data view was loaded. At some
point something changed and now there are system and hidden indices that
require `expandWildcards: hidden` to be passed to field caps in order to
see anything. `allowHidden: boolean` is added to the DataView and
DataViewSpec and passed through when field caps requests are made.
This is primarily a tool for troubleshooting. For instance, instead of
hitting a full data stream across a number of data tiers you can select
a specific index to compare its performance.
Closes: https://github.com/elastic/kibana/issues/164652
Closes https://github.com/elastic/kibana/issues/164683
## Summary
This PR disables the infrastructure, metrics and logs alerts rule in
Serverless:
- Deletes the code responsible for the "Metric Anomaly" rule as it was
[previously disabled](https://github.com/elastic/kibana/pull/93813) with
plans to re-enable it as the previous PR describes but that never
happened.
- Adds feature flags for all three types of alert rules
- Prevents rules registration in serverless based on the feature flags
- Adds logic for showing/hiding items in the "Alerts and rules" dropdown
- Disables custom threshold rule in the Infra UI by default in
serverless as the rule needs to first be enabled by default by
@elastic/actionable-observability team
([context](https://elastic.slack.com/archives/C023GDA0WMP/p1696853751040269))
**Dropdown**
**Host details**
### How to test
- Checkout locally Run in Serveless mode
- Enable, Infra plugin, custom threshold in Infra, and custom threshold
rule in general:
```
xpack.infra.enabled: true
xpack.infra.featureFlags.customThresholdAlertsEnabled: true
xpack.observability.unsafe.thresholdRule.enabled: true
```
- Go to `/app/metrics/hosts` and make sure there are no "Infrastructure"
and "Metrics" items in the "Alerts and rules" dropdown
- Click on "Manage rules" in the "Alerts and rules" dropdown, then
"Create rule" to open the rule selection flyout
- Make sure there are no rules for "Inventory", "Metrics" or "Logs"
threshold
- Run Kibana in traditional mode
- Make sure the "Alerts and rules" dropdown looks as usual and you can
create "Infrastructure" and "Metrics" alerts
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
