**!!MAJORITY OF THE CHANGED FILES ARE MOVED OR COPIED!!**
### Vision
According to the product vision we will build a new simple UI/UX in the
future https://github.com/elastic/security-team/issues/11790
This PR is a first iteration on enabling Content Connectors Management
UI in Serverless Kibana Stack Management.
Elastic Managed content connectors will be available only for Security
and Observability projects.
### Current PR scope
1. Used initial search_connectors plugin and renamed it to
content_connectors + moved from `x-pack/solutions/search` to
`x-pack/platform/plugins/shared`
2. Copy relevant connectors UI and routes from enterprise_search plugin.
3. Introduce the new Stack Management card/navigation option under the
Data section.
4. Enabled this plugin only in Serverless for Security and Observability
projects.
5. For making PR smaller Pipelines tab was not moved. And according to
Search team vision this functionality should be dropped anyway soon.
6. Extended fleet package logic to include elastic_connectors for
security and o11y serverless projects
7. Added back `search:agentless-connectors-manager` task
In Stack Management navigation:
<img width="2062" alt="Screenshot 2025-04-15 at 3 51 43 PM"
src="https://github.com/user-attachments/assets/5c93ba01-9a6a-4eac-a21d-1370f03b8f35"
/>
Stack Management cards:
<img width="2081" alt="Screenshot 2025-04-10 at 8 41 43 PM"
src="https://github.com/user-attachments/assets/3def1c12-561b-4a84-8241-4dd61cd9313d"
/>
Create Elastic Managed Connector UI (on Agentless):
<img width="1822" alt="Screenshot 2025-04-15 at 3 55 29 PM"
src="https://github.com/user-attachments/assets/6e9fea48-85e7-43df-919d-0e5492d0e704"
/>
Create Self Managed Connector UI:
<img width="2064" alt="Screenshot 2025-04-15 at 3 55 49 PM"
src="https://github.com/user-attachments/assets/d5051898-c8fa-4e41-b9ea-b41d4ed4a0d5"
/>
### Next steps
- [ ] Remove duplicated code between content_connectors,
enterprise_search and serverless_search
- [ ] Extract [common server
libs](https://github.com/elastic/kibana/tree/main/x-pack/solutions/search/plugins/enterprise_search/server/lib)
to the shared package `kbn-search-connectors`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Artem Shelkovnikov <artem.shelkovnikov@elastic.co>
Co-authored-by: Artem Shelkovnikov <lavatroublebubble@gmail.com>
Co-authored-by: Kyle Pollich <kyle.pollich@elastic.co>
## Summary
Pre-requisite for https://github.com/elastic/kibana/pull/216088, as the
`AI Assistant Management` configuration settings should be available for
Search too.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes image paths to work with docs-assembler.
Notes for the reviewer:
* I was not able to get images in reference, extend, or release-notes to
work using the `:::{image}` syntax because it seems to resolve
differently than the Markdown `![]()` syntax. We should address this in
docs-builder, but in order to get images working as soon as possible,
I've used Markdown syntax and left us a `TO DO` in a code comment to add
back the `screenshot` class where applicable.
* Can you please add the appropriate labels needed for backporting?
## Summary
Removes unused code from the Investigate and Investigate app plugin.
Removes all references to those plugins in storybook, i18n, types, etc.
Removes codeowner requirements for those plugins
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR adds 9.0 GA release notes for Kibana.
- [x] convert the [9.0.0rc1 release
notes](https://github.com/elastic/stack-docs/blob/9.0/docs/en/install-upgrade/release-notes/release-notes-kibana.asciidoc)
into markdown to prepare for the release to the new docs site
- [x] Add anchors `$$$kibana-PR$$$` to breaking changes for links from
Upgrade Assistant. cc @lcawl FYI
- [x] Run release notes tool for post-rc1 changes
- [x] Reviews
## For reviewers
Preview link:
https://docs-v3-preview.elastic.dev/elastic/kibana/pull/215772/release-notes/
Release notes are adopting a new structure from 9.0, identical across
all Elastic products. Pages are broken down as follows:
- A main page listing all new features, enhancements, and bug fixes.
Each new release gets added to the same page. (9.1 will be above 9.0,
etc.)
- Subpages for breaking changes, deprecations, and known issues.
- There is no longer a "What's new page". This is replaced with a link
to the blog's release announcement from this page, that will be the
"home page" for release notes in the new assembled docs website:
https://staging-website.elastic.co/docs/release-notes/ (not visible in
this PR)
---------
Co-authored-by: wajihaparvez <wajiha.parvez@elastic.co>
## Summary
Resolves: https://github.com/elastic/kibana/issues/190661
This PR allows tasks to be ran scoped as the current user. It
accomplishes this by creating an API when the user schedules this task.
It will then persist the API key in the task instance which allows the
task handler to have access to the user's privileges.
To test:
1. Run `yarn start --run-examples`
2. Navigate to
`http://localhost:5601/app/triggersActionsUiExample/task_manager_with_api_key`
3. Click on `Schedule Task 1 and 2`, this will schedule a mock test that
is defined in
`x-pack/platform/plugins/shared/alerting/server/plugin.ts`, which prints
out the task instance and the scoped clients.
4. Click on `Remove` to cancel the task, which then cleans up and
invalidates the API keys.
5. Reschedule the 2 tasks and click on `Remove All Tasks` which will
bulk remove tasks and invalidate API keys.
Limitation of this approach:
- Because we depend on a request, this would mean every schedule that is
tied to a user needs to be triggered using a request. (Unless we have a
way of generating an API key without using the request).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
~**DO NOT MERGE:** depends on
https://github.com/elastic/kibana/issues/213468~
This PR reintegrates the work from the `workchat_m1` branch into `main`:
- introduces a 4th solution type, `chat`, that will be used for the
*WorkChat* project type.
- edit things in various platform code to introduce/handle that new
project type
- add plugins and packages for the workchat app.
### To AppEx reviewers:
File change count is scary, but you can safely ignore anything from
`xpack/solutions/chat` (given it's solution code), and focus on your
owned changes, which are way more reasonable
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Joe McElroy <joseph.mcelroy@elastic.co>
Co-authored-by: Rodney Norris <rodney.norris@elastic.co>
Co-authored-by: Jedr Blaszyk <jedrazb@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Meghan Murphy <meghan.murphy@elastic.co>
Related to https://github.com/elastic/docs-content/pull/914
Removes reliance on temporary redirects in the docs-content repo.
@florent-leborgne can you help me with backport labels? I always get
mixed up across repos.
This PR resolves [Link color in banner shown in blue and not the defined
color](https://github.com/elastic/kibana/issues/206266) issue.
Now there is a new option added that applies custom color specifically
for links, and can be fully customized.
- Updated documentation
- in Cloud
- advanced-settings
- configuration
- Added to plugins
- kibana_usage
- telemetry
- Implemented new 'linkColor' property for the banners
- Updated functional tests
## Summary
A [recent PR](https://github.com/elastic/kibana/pull/212558/files) (3
weeks ago) migrated docs under `/docs` folder, from `.asciidoc` to
`.md`.
Unfortunately, some of these docs (well, at least one) were generated
automatically using a script:
`node scripts/build_plugin_list_docs.js` was updating the
`docs/developer/plugin-list.asciidoc`
As a result of the migration:
The CI pipeline step fails, and the list of plugins is no longer
updated.
Besides:
* The https://www.elastic.co/guide/en/kibana/current/plugin-list.html is
currently broken.
* This page is (or should be) built from
https://github.com/elastic/kibana/blob/main/docs/extend/plugin-list.md,
which is also broken.
They are broken cause some plugins' descriptions use the pipe `|`
character, which breaks the Markdown layout.
This PR updates the logic that generates the plugin-list, switching from
`.asciidoc` to `.md`, and escaping `\n` and `|` characters to allow for
better descriptions.
This updates the versioning tags in the Alert and Action settings yaml
file to use `all` instead of `ga`. I guess the former makes more sense
since these settings aren't newly GAed.
The PR also makes a couple of very minor content changes based on
https://github.com/elastic/kibana/pull/214934
This PR:
- Makes a backup copy of the `kibana-alert-action-settings.yml` file
just in case I mess things up badly.
- Converts all of the descriptions and examples in the original file to
Markdown format.
- Adds the versioning info as follows:
- supported on ESS/ECH:
```
applies_to:
stack: ga
deployment:
self: ga
ess: ga
```
- not supported on ESS/ECH:
```
applies_to:
stack: ga
deployment:
self: ga
```
In the current Kibana settings docs we indicate settings available on
ESS/ECH. We don't indicate anything for other deployment types such as
ECK or ECE. I assume that no settings are available on Serverless. So,
the above versioning basically just copies what we document currently.
Once merged, I expect that we can test rendering the docs HTML pages
(like [this
one](https://www.elastic.co/guide/en/kibana/8.x/alert-action-settings-kb.html))
directly from this [YAML
source](https://github.com/elastic/kibana/blob/main/docs/settings-gen/source/kibana-alert-action-settings.yml).
@florent-leborgne and @wajihaparvez Sorry, I know this is kind of big.
I'd appreciate any input, especially on the versioning / `applies_to`
part since that's still a bit new.
Just for my own reference, I cut and pasted all of the Markdown from
[here](https://github.com/elastic/asciidocalypse/blob/main/docs/kibana/docs/reference/configuration-reference/alerting-settings.md?plain=1).
Closes: https://github.com/elastic/ingest-docs/issues/1659
In https://github.com/elastic/docs-builder/pull/699, we added the
ability to pass arguments to code blocks. In this repo, there are a few
code blocks that list two languages (`typescript jsx`). The docs-builder
interprets the second language `jsx` as an argument, but `jsx` is not a
valid argument so it throws an error. This should fix the `docs-build`
check.
cc @elastic/docs-engineering
Migrate docs from AsciiDoc to Markdown. The preview can be built after
#212557 is merged.
@florent-leborgne please tag reviewers, add the appropriate label(s),
and take this out of draft when you're ready.
Note: More files are deleted than added here because the content from
some files was moved to
[elastic/docs-content](https://github.com/elastic/docs-content).
**What has moved to
[elastic/docs-content](https://github.com/elastic/docs-content)?**
Public-facing narrative and conceptual docs have moved. Most can now be
found under the following directories in the new docs:
- explore-analyze: Discover, Dashboards, Visualizations, Reporting,
Alerting, dev tools...
- deploy-manage: Stack management (Spaces, user management, remote
clusters...)
- troubleshooting: .... troubleshooting pages
**What is staying in the Kibana repo?**
- Reference content (= anything that is or could be auto-generated):
Settings, syntax references
- Release notes
- Developer guide
---------
Co-authored-by: Florent Le Borgne <florent.leborgne@elastic.co>
This PR reproduces https://github.com/elastic/kibana/pull/212514 to make
it simpler to backport down to the 8.13 version.
I'll port the change to the new location for 9.0+ docs as well.
## Summary
The `/packages` folder at the root of the Kibana repository used to
contain a lot of packages.
In the context of SKA, they have been gradually moved to various
locations:
* `src/platform/packages`
* `x-pack/platform/packages`
* `src/core/packages`
Currently, only `devOnly: true` packages are left in this folder. This
comprises libraries for CLI scripts as well as testing utilities.
With this PR, we are moving ~half of these packages under
`src/platform/packages/(private|shared)/`.
In particular, we are moving those packages that are being used from
platform and/or solutions.
Since they are `"devOnly": true`, this means they are ONLY used from
tests, cypress tests, storybook configs, ./scripts/ folders inside some
modules, or other non-prod-time logic. Nonetheless, they are effectively
referenced from platform and/or solutions code, hence I decided they
should be placed under `platform` folders.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 3 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/observability-utils-browser` |
`x-pack/solutions/observability/packages/utils-browser` |
| `@kbn/observability-utils-common` |
`x-pack/solutions/observability/packages/utils-common` |
| `@kbn/observability-utils-server` |
`x-pack/solutions/observability/packages/utils-server` |
<details >
<summary>Updated references</summary>
```
./package.json
./packages/kbn-ts-projects/config-paths.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./tsconfig.base.json
./x-pack/solutions/observability/packages/utils-browser/jest.config.js
./x-pack/solutions/observability/packages/utils-common/jest.config.js
./x-pack/solutions/observability/packages/utils-server/jest.config.js
./x-pack/solutions/observability/packages/utils-server/jest.integration.config.js
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
x-pack/solutions/observability/packages/utils-browser/jest.config.js:10
x-pack/solutions/observability/packages/utils-browser/tsconfig.json:2
x-pack/solutions/observability/packages/utils-common/jest.config.js:10
x-pack/solutions/observability/packages/utils-common/tsconfig.json:2
x-pack/solutions/observability/packages/utils-server/jest.config.js:10
x-pack/solutions/observability/packages/utils-server/jest.integration.config.js:10
x-pack/solutions/observability/packages/utils-server/tsconfig.json:2
```
</details>
## Summary
* Categorise and move `@kbn/timelines-plugin` as _platform/shared_,
target location: `x-pack/platform/plugins/shared/timelines`.
This helps reduce the scope of the illegal dependencies from `osquery`
plugin towards _security/private_ code.
cc @tomsonpl
* Simplify path and rename `@kbn/observability-alerting-rule-utils`
(platform/shared):
```
# Before
@kbn/observability-alerting-rule-utils
x-pack/platform/packages/shared/observability/alerting_rule_utils/
# After
@kbn/alerting-rule-utils
x-pack/platform/packages/shared/alerting_rule_utils/
```
* Simplify path and rename `@kbn/observability-logs-overview`
(platform/shared):
```
# Before
@kbn/observability-logs-overview
x-pack/platform/packages/shared/observability/logs_overview/
# After
@kbn/logs-overview
x-pack/platform/packages/shared/logs_overview/
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
fix https://github.com/elastic/kibana/issues/209081
Updates UI copy for the batch reindexing API only supporting indices.
Note to reviewers: There wasn't an entry for the translation id for
French.
---------
Co-authored-by: Jean-Louis Leysens <jloleysens@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR reworks saved query privileges to rely solely on a single global
`savedQueryManagement` privilege, and eliminates app-specific overrides.
This change simplifies the security model for users, fixes bugginess in
the saved query management UI, and reduces code complexity associated
with maintaining two separate security mechanisms (app-specific
overrides and global saved query management privileges).
### Background
Saved queries allow users to store a combination of KQL or Lucene
queries, filters, and time filters to use across various applications in
Kibana. Access to saved query saved objects are currently granted by the
following feature privileges:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_savedQueryManagement.all",
"feature_maps.all",
"feature_savedObjectsManagement.all",
"feature_visualize.all"
]
```
There is also a saved query management UI within the Unified Search bar
shared by applications across Kibana:
<img
src="https://github.com/user-attachments/assets/e4a7539b-3dd4-4d47-9ff8-205281ef50e3"
width="500" />
The way access to this UI is managed in Kibana is currently confusing
and buggy:
- If a user has `feature_discover.all` and `feature_dashboard.all` they
will be able to load and save queries in Discover and Dashboard.
- If a user has `feature_discover.all` and `feature_dashboard.read` they
will be able to load queries in both Discover and Dashboard, but only
save queries in Discover (even though they have write access to the SO,
and API access). Instead they have to navigate to Discover to save a
query before navigating back to Dashboard to load it, making for a
confusing and frustrating UX.
- Access to the UI is even more confusing in apps not listed in the
above feature privileges (e.g. alerting, SLOs). Some of them chose to
check one of the above feature privileges, meaning users who otherwise
should have saved query access won't see the management UI if they don't
also have the exact feature privilege being checked. Other apps just
always show the management UI, leading to bugs and failures when users
without one of the above feature privileges attempt to save queries.
### Existing improvements
In v8.11.0, we introduced a new ["Saved Query
Management"](https://github.com/elastic/kibana/pull/166937) privilege,
allowing users to access saved queries across all of Kibana with a
single global privilege:
<img
src="https://github.com/user-attachments/assets/ccbe79a4-bd0b-4ed6-89c9-117cc1f99ee2"
width="600" />
When this privilege is added to a role, it solves the
`feature_discover.all` and `feature_dashboard.read` issue mentioned
above. However, it does not fix any of the mentioned issues for roles
without the new privilege. We have so far postponed further improvements
to avoid a breaking change.
### Approach
To fully resolve these issues and migrate to a single global privilege,
these changes have been made:
- Remove saved query SO access from all application feature privileges
and instead only allow access through the global saved query management
privilege.
- Stop relying on application feature privileges for toggling the saved
query management UI, and instead rely on the global privilege.
To implement this with minimal breaking changes, we've used the Kibana
privilege migration framework. This allows us to seamlessly migrate
existing roles containing feature privileges that currently provide
access to saved queries, ensuring they are assigned the global saved
query management privilege on upgrade.
As a result, we had to deprecate the following feature privileges,
replacing them with V2 privileges without saved query SO access:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_maps.all",
"feature_visualize.all"
]
```
Each area of code that currently relies on any of these feature
privileges had to be updated to instead access `feature_X_V2` instead
(as well as future code).
This PR still introduces a minor breaking change, since users who have
`feature_discover.all` and `feature_dashboard.read` are now able to save
queries in Dashboard after upgrade, but we believe this is a better UX
(and likely the expected one) and worth a small breaking change.
### Testing
- All existing privileges should continue to work as they do now,
including deprecated V1 feature privileges and customized serverless
privileges. There should be no changes for existing user roles apart
from the minor breaking change outlined above.
- Check that code changes in your area don't introduce breaking changes
to existing behaviour. Many of the changes are just updating client UI
capabilities code from `feature.privilege` to `feature_v2.privilege`,
which is backward compatible.
- The `savedQueryManagement` feature should now globally control access
to saved query management in Unified Search for all new user roles.
Regardless of privileges for Discover, Dashboard, Maps, or Visualize,
new user roles should follow this behaviour:
- If `savedQueryManagement` is `none`, the user cannot see or access the
saved query management UI or APIs.
- If `savedQueryManagement` is `read`, the user can load queries from
the UI and access read APIs, but cannot save queries from the UI or make
changes to queries through APIs.
- If `savedQueryManagement` is `all`, the user can both load and save
queries from the UI and through APIs.
### 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]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] 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)
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
This PR risks introducing unintended breaking changes to user privileges
related to saved queries if the deprecated features have not been
properly migrated, and users could gain or lose access to saved query
management on upgrade. This would be bad if it happened, but not overly
severe since it wouldn't grant them access to any ES data they couldn't
previously access (only query saved objects). We have automated testing
in place to help ensure features have been migrated correctly, but the
scope of these changes are broad and touch many places in the codebase.
Additionally, the UI capabilities types are not very strict, and are
referenced with string paths in many places, which makes changing them
riskier than changing strictly typed code. A combination of regex
searches and temporarily modifying the `Capabilities` type to cause type
errors for deprecated privileges was used to identify references in
code. Reviewers should consider if there are any other ways that UI
capabilities can be referenced which were not addressed in this PR.
Our automated tests already help mitigate the risk, but it's important
that code owners thoroughly review the changes in their area and
consider if they could have unintended consequences. The Platform
Security team should also review this PR thoroughly, especially since
some changes were made to platform code around privilege handling. The
Data Discovery team will also manually test the behaviour when upgrading
existing user roles with deprecated feature privileges as part of 9.0
upgrade testing.
---------
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: Matthias Wilhelm <ankertal@gmail.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
That way we can internally link to this beautiful section using
`<<angle-brackets-and-stuff>>`
---------
Co-authored-by: florent-leborgne <florent.leborgne@elastic.co>
## Summary
Adding a note that for logs, in case the name of the filebeat index was
changed, it's needed to adjust `monitoring.ui.logs.index` so that the
logs stats can be retrieved as well
## Summary
Part of https://github.com/elastic/kibana/issues/203925.
Resolves https://github.com/elastic/kibana/issues/205813.
Adds warning messages to the upgrade assistant if a cluster has
unexpired search sessions, since the feature is being disabled by
default and will have to be explicitly re-enabled to manage the
sessions.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
## Summary
Resolves https://github.com/elastic/kibana/issues/199616
Added a debug logger when calling deprecated APIs. This logger is
disabled by default, to enable it you have to set
`deprecation.enable_http_debug_logs: true`.
To test this you can play with the config value and do a request like
this to a deprecated endpoint:
```shell
#!/bin/bash
API_KEY=""
curl -X GET "http://localhost:5601/api/cases/status" -i \
-H "Content-Type: application/json" \
-H "Authorization: ApiKey $API_KEY"
```
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: florent-leborgne <florent.leborgne@elastic.co>
Co-authored-by: Jean-Louis Leysens <jloleysens@gmail.com>
