Skip to content

[ResponseOps][Connectors] Add authMode to connector saved objects and apis#252064

Closed
js-jankisalvi wants to merge 157 commits intoelastic:connectors-auth-code-grantfrom
js-jankisalvi:connector-auth-mode
Closed

[ResponseOps][Connectors] Add authMode to connector saved objects and apis#252064
js-jankisalvi wants to merge 157 commits intoelastic:connectors-auth-code-grantfrom
js-jankisalvi:connector-auth-mode

Conversation

@js-jankisalvi
Copy link
Copy Markdown
Contributor

@js-jankisalvi js-jankisalvi commented Feb 6, 2026

Summary

Resolves #250976

This PR introduces a new authMode attribute for connectors that allows configuring authentication modes as either shared (default) or per-user. This enables support for different authentication patterns where connectors can use:

  • shared: Single set of credentials shared across all users
  • per-user: Individual user credentials for personalized authentication

Key Changes

  • New API field: Added optional auth_mode parameter to connector create endpoint
  • Saved object schema: Introduced v2 schema with authMode field support
  • Data migration: Model version 2 automatically backfills authMode: 'shared' for existing connectors that have config.authType set

Note: Update API does not support authMode as of now.

How to test

  1. Create two connectors in main one with authType and one without
curl -X POST "http://localhost:5601/api/actions/connector" \
  -H "kbn-xsrf: true" \
  -H "Content-Type: application/json" \
  -u elastic:changeme \
  -d '{
    "name": "My Webhook Connector",
    "connector_type_id": ".webhook",
    "config": {
        "url": "https://api.example.com/webhook",
        "method": "post",
        "hasAuth": true,
        "authType": "webhook-authentication-basic", 
        "headers": {
          "Content-Type": "application/json"
        }
      },
    "secrets": {
      "user": "admin",
      "password": "secret"
    },
  }'
  • Checkout this PR and restart kibana
  • Verify that connector with authType has authMode: shared and connector without authType doesn't
    curl -X GET "http://localhost:5601/api/actions/connectors" \
      -H "kbn-xsrf: true" \
      -u elastic:changeme
    
  1. Create connector with authMode
curl -X POST "http://localhost:5601/api/actions/connector" \
  -H "kbn-xsrf: true" \
  -H "Content-Type: application/json" \
  -u elastic:changeme \
  -d '{
    "name": "Shared Auth Webhook",
    "connector_type_id": ".webhook",
    "config": {
      "url": "https://example.com/webhook",
      "method": "post"
    },
    "secrets": {
      "user": "admin",
      "password": "secret"
    },
    "auth_mode": "shared"
  }'

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

  • Documentation was added for features that require explanation or tutorials
  • Unit or functional tests were updated or added to match the most common scenarios
  • The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines
  • Review the backport guidelines and apply applicable backport:* labels.

Release note:

Create a connector with auth_mode attribute

stratoula and others added 30 commits February 4, 2026 10:49
## Summary

Closes elastic#251272

Makes the test less flaky (I introduced the flakiness with my
performance optimizations)

### Checklist
- [ ] [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
resolves elastic#248391

## Summary

This fixe stops the signature popup from appearing when hovering over
operators.

### Checklist

Check the PR satisfies following conditions. 

Reviewers should verify this PR satisfies this list as well.
- [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)
- [x] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable `backport:*` labels.

---------

Co-authored-by: Stratou <efstratia.kalafateli@elastic.co>
…c#251009)

## Summary

To reduce the time spent on FTR in lens group4 and group7, I've moved
TSDB and LogsDB tests into separate groups so we can have a better
control over their timing.

The same happened to the same tests in serverless where I split them
into 2 groups (standard scenario and downgrade scenario).
This resulted in more test groups but with smaller run time, going from
a 45 minutes to 2 parallel test in 20/25 minutes.

Files `index.ts` and `config.ts` are adjusted accordingly and are
duplicated as is to the newly created groups.

The README was coded with the support of AI.
Automated by
https://buildkite.com/elastic/package-storage-infra-kibana-discover-release-branches/builds/4082

Co-authored-by: elastic-vault-github-plugin-prod <elasticmachine@elastic.co>
Co-authored-by: Julia Bardi <90178898+juliaElastic@users.noreply.github.com>
## Summary

This change improves how the Index Details page fetches data by reducing
unnecessary polling to backend APIs. Previously, the page repeatedly
polled two endpoints to keep index metadata up to date, even when the
data was not actively changing or required for user interaction.

As part of this update, we reviewed the polling strategy used for:

`GET /api/index_management/mapping/{index_name}`
`GET /internal/index_management/indices/{index_name}`
`POST /internal/search_indices/${indexName}/documents/search`

and adjusted the behavior to better align with how the data is used on
the page.

### What changed
- Polling behavior has been reduced or scoped so that requests are only
made on initial load, on window focus, and when requested.
- A `Refresh data` button was added to allow users to request up to date
data.
- `useUserPrivilegesQuery` no longer refetches on window focus, which is
the default behavior.
- The `queryKey` in `useUserPrivilegesQuery` has been updated to add the
`indexName`.

### Screenshots

**Index with documents**
<img width="700" height="828" alt="Screenshot 2026-02-03 at 13 24 12"
src="https://github.com/user-attachments/assets/c8a99e1e-4f67-4bfd-9b7a-4c7490f8cb7d"
/>

**Index without documents**
<img width="700" height="829" alt="Screenshot 2026-02-03 at 13 24 26"
src="https://github.com/user-attachments/assets/8d752199-2ecf-47e6-b47e-f1966590f0c2"
/>

### Checklist

Check the PR satisfies following conditions. 

Reviewers should verify this PR satisfies this list as well.

- [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/src/platform/packages/shared/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~
- [ ] ~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 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)
- [x] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable `backport:*` labels.

## Release note

Reduced background polling on the Index Details page to avoid
unnecessary API requests.
### Summary

Introduce an initial evaluation suite for feature identification. The
suite runs four LLM-generated datasets:
- Obvious evidence: explicit version strings / clear signals
- Inference required: indirect signals (ecosystem/library cues) to
validate inference tagging
- Ambiguous evidence: weak or conflicting hints to ensure the model
remains conservative and avoids over-identifying
- False positives: misleading mentions in user content

Evaluation currently uses an LLM-as-a-judge approach via criteria. There
are known limitations (synthetic data, subjectivity..) but this initial
evaluation is intended as a baseline and a specification of expected
behavior that should provide a good starting point.

### Testing

- Start scout server

```
node scripts/scout.js start-server --stateful
```

- Run evaluations

```
EVALUATION_CONNECTOR_ID=<evaluator-llm> node scripts/playwright test \
  --config x-pack/platform/packages/shared/kbn-evals-suite-streams/playwright.config.ts \
  --project <identification-llm> \
  --grep "features identification"
  ```

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 🍒 Summary

Removes the temporary workaround in the streams processing simulation
handler that suppressed `geo.location` ignored field errors for OTEL
streams. This workaround is no longer needed since the underlying
Elasticsearch bug has been fixed.

## 🛠️ Changes

- Removed the `isOtelStream` import from `@kbn/streams-schema` as it was
only used for this workaround
- Simplified `collectIngestDocumentErrors` function by removing the
`otelStream` parameter and the filtering logic that suppressed
geo.location ignored field errors
- Removed the `otelStream` parameter from
`computePipelineSimulationResult` function
- Removed the `otelStream` variable calculation in `simulateProcessing`
function
- Added a new test case to verify geo.location fields are properly
handled in OTEL streams

## 🎙️ Prompts

- Remove the geo.location workaround from the streams processing
simulation handler that was added as a bandaid for
elastic/elasticsearch#140506, which has been
fixed in elastic/elasticsearch#141397

🤖 This pull request was assisted by Cursor
…les (elastic#251442)

## Summary

Fixes an issue where span.links data that is not an array (e.g., null,
object, or string) would cause trace sample requests to fail or return
empty responses. This can occur with certain OTel data formats.

### Changes:
- Replace ?? operator with explicit `Array.isArray()` check to ensure
`span.links` is always an array before calling `.filter()`
- Add comprehensive unit tests for malformed data scenarios
- Covers cases where `span.links` is null, object, string, or other
non-array values

BEFORE

<img width="2880" height="2084" alt="image"
src="https://github.com/user-attachments/assets/d853554d-0bb5-4451-bc8e-bea16f5560f8"
/>

AFTER


https://github.com/user-attachments/assets/8f3fb7b8-77e5-484f-bfbe-9ffed89c9f0c
## Summary

This PR fixes a problem we saw when cancelling the serverless quality
gate bake time early.

### The observed problem

When manually cancelling the bake time time step early, it used to come
back with exit code `255`, which we treated as a soft-fail in order to
allow such manual action without failing the whole quality gates job. In
a recent run, this didn't work anymore as the manually cancelled step
came back with an exit code of `-1` which we didn't catch as soft-fail,
so it failed the whole job and thus the promotion.

After checking back with Buildkite support, it turned out that with
recent updates in Buildkite agent versions, the behavior changed indeed
and the exit code `-1` is now the expected behavior for cancelled steps.

### The fix

Following the guidance we've got from Buildkite, this PR adds an input
step that allows to manually cancel the bake time. This makes use of
Buildkite meta-data, which is regularly checked during the bake time
wait. If the corresponding meta-data key is found, the wait command
exits with a code of 42, which is properly propagated to the BK step
result where we can catch it to make the step soft-fail.

To make it more visible, this also adds a BK job annotation:

<img width="338" height="138" alt="image"
src="https://github.com/user-attachments/assets/c386ea9f-b7ad-4652-a12e-10083cbb569c"
/>


### Notes for reviewers

- When editing the quality gate yaml files, the auto-format turned all
the double quotes into single quotes on save. I've applied it to all
definitions under `.buildkite/pipelines/quality-gates/` and, for an
easier review, put that into a separate commit
(e1db4e1).
- The actual pipeline change is in the second commit
(b2e9fcd).
- Pipeline runs to demonstrate the changes (dummy runs without actual
promotion)
- regular canary run without bake time cancel:
https://buildkite.com/elastic/kibana-tests-emergency/builds/91
- as of writing this, it's still running the 24 hours bake time - here's
an earlier trial job with reduced other checks, an artificial 60 seconds
bake time and quicker updates which demonstrates how it'll look like:
https://buildkite.com/elastic/kibana-tests-emergency/builds/87
- canary run with bake time cancelled earlier:
https://buildkite.com/elastic/kibana-tests-emergency/builds/92
- noncanary run, where there's no bake time and no option to cancel it:
https://buildkite.com/elastic/kibana-tests-emergency/builds/94
This is a follow up PR to this
[one](elastic#245371) that improves tests
and addresses:

- [search_slo_definitions integration
tests](x-pack/solutions/observability/test/api_integration_deployment_agnostic/apis/slo/search_slo_definitions.ts):
no need to create SLOs for the test, since we rely only on summary
documents. We can just insert a bunch of summary documents with various
names, etc...
- [search_slo_definitions unit
tests](x-pack/solutions/observability/plugins/slo/server/services/search_slo_definitions.ts):
add some checks on the size > 0 && size <= 100

cc @kdelemme

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
… array (elastic#250279)

## Summary
When a user would attempt to create a new exception list and they
included `os_types` in the request body, the created list would not save
or return the desired `os_types`.

## Changes
The root of the issue was that `os_types` was not being extracted from
the request body. This led to the downstream creation never receiving
the value. I added the field to the `CreateExceptionListOptions` type in
order for the `createExceptionList` to accept it. The downstream client
function and type were also updated. The duplication service was also
updated.
## Summary

This PR introduces a new shared package `@kbn/esql-resource-browser`
that contains the ES|QL resource browser components that will be later
introduced in the ES|QL editor.

## Changes

Created a new shared package containing the following components:

- **`DataSourceBrowser`** - A popover component for browsing and
selecting data sources (indices, data streams, integrations, lookup
indices, timeseries)
- **`FieldsBrowser`** - A popover component for browsing and selecting
fields from a specific data source
- **`BrowserPopoverWrapper`** - A shared wrapper component that provides
consistent popover behavior, search, and filtering UI

### Key Features

- **Type filtering** - Both browsers support filtering by type (source
type or field type)
- **Search** - Full-text search within the browser lists
- **Pre-selection** - `DataSourceBrowser` supports pre-selecting sources
that are already in the query


## How to Test

Run Storybook:
`yarn storybook esql_resource_browser`
or test directly in the CI Storybook deployment in this PR


https://github.com/user-attachments/assets/2e1f0548-eb10-4080-b4a3-e0221e7f115a

## Figma mockups

Note: The filter badges were discussed on Slack but have not been added
in the mockups yet. Also, the Recommended/Available fields sections in
the fields browser are only available when they are set up through an
extension service (currently only in Oblt solution).

<img width="545" height="383" alt="Screenshot 2026-01-29 at 17 04 13"
src="https://github.com/user-attachments/assets/8798661d-7960-4d76-a8d5-a1c7e3fcd058"
/>

<img width="564" height="383" alt="Screenshot 2026-01-29 at 17 04 29"
src="https://github.com/user-attachments/assets/00cc9c55-eae8-46d4-bc00-c7025ec95899"
/>

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
…eter to have more than 1 value

## Summary

This pull request introduces support for multi-K evaluation in RAG
metrics, improves evaluator selection patterns, and updates
documentation and tests to reflect these changes. The main focus is to
allow users to specify multiple K values for RAG evaluators via
environment variables, enforce the use of pattern-based selection for
RAG metrics, and ensure consistent naming and filtering of evaluators.

**Evaluator selection and filtering improvements:**

- Added support for pattern-based selection of RAG evaluators
(`Precision@K`, `Recall@K`, `F1@K`) in the `SELECTED_EVALUATORS`
environment variable, disallowing direct selection of K-specific names
like `Precision@10`. The filtering logic now matches all relevant
K-specific evaluators when a pattern is used.
[[1]](diffhunk://#diff-2755b08d1642c0847090b47bea6d5669406b09733dcb93360beb2d36c12d338cR10-R43)
[[2]](diffhunk://#diff-2755b08d1642c0847090b47bea6d5669406b09733dcb93360beb2d36c12d338cL27-R63)
[[3]](diffhunk://#diff-6ce1b5ed36a79b676f896c4ff10b4e69f42bde242f8ae0fdd7ad3d0745ecb325R1-R162)
- Updated the documentation and CLI environment variable help to clarify
the use of evaluator patterns and how to specify multiple K values.
[[1]](diffhunk://#diff-31f7638b7f498e151ed9c689d4a381573875ccd43fabb0a44b464d2acf131799L48-R56)
[[2]](diffhunk://#diff-1b94c98bccf3582d12dc15a66985e80ada84eccabfda7e32bbca798a53b32473R475-R483)
[[3]](diffhunk://#diff-1922942928189e112cb1b4c133ecb5b8d37f70971727565deaefcd5c600a12adL129-R133)

**RAG evaluator creation and naming:**

- Refactored RAG evaluator creation to generate evaluators for each
specified K value (from config or the `RAG_EVAL_K` environment
variable), deduplicate and sort K values, and ensure evaluator names are
consistently formatted as `Metric@K` (e.g., `Precision@10`).
[[1]](diffhunk://#diff-942cf345788d2132cbc1c1bdc4fe185ffef09d5a4647af7471a57407b3c176f6L20-R22)
[[2]](diffhunk://#diff-942cf345788d2132cbc1c1bdc4fe185ffef09d5a4647af7471a57407b3c176f6L33-R67)
- Updated evaluator explanation messages and error handling to use the
specific K value in all output and error messages.
[[1]](diffhunk://#diff-942cf345788d2132cbc1c1bdc4fe185ffef09d5a4647af7471a57407b3c176f6L59-R84)
[[2]](diffhunk://#diff-942cf345788d2132cbc1c1bdc4fe185ffef09d5a4647af7471a57407b3c176f6R113-R115)
[[3]](diffhunk://#diff-942cf345788d2132cbc1c1bdc4fe185ffef09d5a4647af7471a57407b3c176f6L99-R125)
[[4]](diffhunk://#diff-942cf345788d2132cbc1c1bdc4fe185ffef09d5a4647af7471a57407b3c176f6L109-R135)
[[5]](diffhunk://#diff-942cf345788d2132cbc1c1bdc4fe185ffef09d5a4647af7471a57407b3c176f6R153-R155)

**Testing enhancements:**

- Added and expanded tests to cover multi-K evaluator creation,
pattern-based filtering, environment variable overrides, and correct
metric calculation for different K values.
[[1]](diffhunk://#diff-6ce1b5ed36a79b676f896c4ff10b4e69f42bde242f8ae0fdd7ad3d0745ecb325R1-R162)
[[2]](diffhunk://#diff-69a17e4c0354cfe832501f207e2aa2ecb32f36545f310643b92c2a705064acf8L8-R13)
[[3]](diffhunk://#diff-69a17e4c0354cfe832501f207e2aa2ecb32f36545f310643b92c2a705064acf8R448-R640)


Results:
Single K 
<img width="1255" height="359" alt="Screenshot 2026-01-29 at 1 44 33 PM"
src="https://github.com/user-attachments/assets/0bce315d-db5f-4a85-904f-8e175d72c21d"
/>

Multiple K:
<img width="1735" height="892" alt="Screenshot 2026-01-29 at 1 41 40 PM"
src="https://github.com/user-attachments/assets/ea243829-650c-4545-9f84-c45ea12f878c"
/>


#Note: Created with Cursor (Cluade)

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary

Upgrade `lodash` from `v4.17.21` to `v4.17.23`

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Part of elastic#239425

Kibana-presentation team is working on "Dashboards as code" project.
Dashboard REST API state contains drilldown state. This PR refactors
drilldown state and provides schemas for drilldown state.

### Before
In the image below, notice how drilldown state is passed as `{
enhancements: { dynamicActions: events: [ {
...messyStateWithClassStructures } ] } }`. This shape leaks Kibana
registry design and class structures into dashboards as code REST API.
<img width="2045" height="1061" alt="Screenshot 2026-01-21 at 4 27
31 PM"
src="https://github.com/user-attachments/assets/6019b43c-c051-40b9-aa0d-d7d1349ba595"
/>

### After
In the image below, notice how drilldown state is passed as `{
drilldowns: [ {...cleanState } ] }`. Now the dashboards as code REST API
does not leak Kibana registry design or class structures.
<img width="2046" height="917" alt="Screenshot 2026-01-27 at 12 18
32 PM"
src="https://github.com/user-attachments/assets/00e09673-2f6f-4af5-8a63-6823d31d6fbc"
/>

### Overview of changes
* EmbeddableServerSetup changes
* Adds `registerDrilldown`, allowing drilldowns to register schemas and
transforms.
* Changes `registerTransforms` shape from `{ transformIn, transformOut,
...otherProps }` to `{ getTransforms, ...otherProps }`. This change is
done to pass `drilldownTransforms` to embeddable transform
implementations. `drilldownTransforms` is stateful because it uses the
contents of drilldown registry.
* Removes `transformEnhancementsIn` and `transformEnhancementsOut` from
interface. Instead of exposing drilldown tranforms directly from
EmbeddableServerSetup, `drilldownTransforms` is provided to embeddables
as a prop to `getTransforms`
* Registers schema and transforms for all drilldown types;
dashboard_drilldown, discover_drilldown, and url_drilldown
* Updates all usages of `registerTransforms` to provide `{
getTransforms, ...otherProps }` instead of `{ transformIn, transformOut,
...otherProps }`
* Updates all usages of `transformEnhancementsIn` and
`transformEnhancementsOut` to use `drilldownTransforms`

### What this PR does not do
To limit scope as much as possible, this PR does not refactor client
code to use the new drilldown format. As a stop gap, a translation layer
is in place that converts `drilldowns` to `enhancements`. Then, on save,
`enhancements` are converted back to `drilldowns` before sending state
across the dashboard REST API. In a follow up PR(s), this translation
layer will be removed and drilldown client code will be refactored to
work directly with `DrilldownsState`

### External team testing
If your embebbable type does not support drilldowns then there is
nothing to test.

If your embeddable type does support drilldowns, then run the following
* install your favorite data set or use one of the sample data sets that
ship with kibana
* Open dashboard application and create a new dashboard
* Add a panel for your embeddable type
* Add one or more drilldowns to this panel
* Save dashboard
* Inspect network requests (filtering by `/api/dashboards`). Notice that
drilldowns are passed as `drilldowns` instead of `enhancements`.
* Open dashboard and verify drilldowns still work as expected
* Open dashboards with drilldowns created from 9.3 cloud instance and in
sure drilldowns still function as expected.

---------

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary

On smaller screen sizes, the Index Details (solution space) page header
would wrap in a way that pushed the three-dot menu onto its own row.
This change groups the three-dot menu with the adjacent action button,
ensuring that when wrapping occurs, the menu is not left isolated on a
separate line.

| Before | After |
| ------ | ------ |
| <img width="200" height="668" alt="Screenshot 2026-02-03 at 17 56 50"
src="https://github.com/user-attachments/assets/26e5aeab-64fe-498f-82c7-fb0d006c1bf5"
/> | <img width="200" height="671" alt="Screenshot 2026-02-03 at 17 57
27"
src="https://github.com/user-attachments/assets/78bbb661-bd8e-41dd-aeca-9f8469d32915"
/> |

| Before | After |
| ------ | ------ |
| <img width="200" height="667" alt="Screenshot 2026-02-03 at 17 55 43"
src="https://github.com/user-attachments/assets/42a3b609-1ea2-4434-a814-af18c7ac40f9"
/> | <img width="200" height="671" alt="Screenshot 2026-02-03 at 17 55
02"
src="https://github.com/user-attachments/assets/4a13638c-8bee-4767-9959-b919f8ed2cee"
/> |


### Checklist

Check the PR satisfies following conditions. 

Reviewers should verify this PR satisfies this list as well.

- [ ] ~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/src/platform/packages/shared/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~
- [ ] ~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 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~
- [ ] ~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)~
- [x] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable `backport:*` labels.
## Summary

Implements API contract for improved case templates. This is only about
the routes / responses - to unblock frontend development. Actual data
logic will be implemented in a future PR.

Resolves elastic/security-team#14975

## Testing
Make sure `xpack.cases.templates.enabled: true` is set in your
`kibana.dev.yml`

Just point your browser / http client (with active kibana session) to
any internal route created here
with `?elasticInternalOrigin` query param appended to the URL.

### Checklist

Check the PR satisfies following conditions. 

Reviewers should verify this PR satisfies this list as well.

- [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

This PR removes the generated OAS bundle files from git source control
tracking:
- `oas_docs/bundle.json` (6.0MB)
- `oas_docs/bundle.serverless.json` (5.9MB)

These files are already listed in `.gitignore` and should not be tracked
in version control. They are generated artifacts that can be rebuilt as
needed and contribute unnecessary bloat to the repository history.

## Changes

- Removed `oas_docs/bundle.json` and `oas_docs/bundle.serverless.json`
from git tracking using `git rm --cached`
- Files remain in `.gitignore` to prevent future tracking
- Local copies of the files are preserved

## Test plan

- Verify the files are no longer tracked by git
- Confirm the files still exist locally after the change
- Ensure the files remain in `.gitignore`

Made with [Cursor](https://cursor.com)

Co-authored-by: Cursor <cursoragent@cursor.com>
## Summary
Closes elastic#250734

This PR fixes the flakiness by using setAbsoluteRangeInRootContainer to
set date range.
## Summary

This PR fixes [Failing test: X-Pack Saved Object Tagging Functional
Tests](elastic#234592) issue.
(More details in the description.)
…ver (elastic#251461)

## Summary

[See issue](elastic#250338)



https://github.com/user-attachments/assets/96837c20-f28e-4269-b2cd-6e2f8d77b9b8


### Checklist

Check the PR satisfies following conditions. 

Reviewers should verify this PR satisfies this list as well.

- [ ] 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/src/platform/packages/shared/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
- [ ] 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 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
- [ ] 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)
- [ ] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable `backport:*` labels.
…#250857)

## Summary

If a yaml definition defines the type names in lowercase, like in the
cases codebase, the generator would generate lowercase type/schema
names. This is against our eslint rules.

```yaml
in: query
name: assignees
description: >
  Filters the returned cases by assignees.
  Valid values are `none` or unique identifiers for the user profiles.
  These identifiers can be found by using the suggest user profile API.
```

would generate:

```ts
export type assignees = z.infer<typeof assignees>; // <-- ESLint error
export const assignees = z.array(...)
```

This PR adds a transformSchemaName option that allows to transform the
schema names to `PascalCase`.

That allows us to generate the correct schema names without having to
touch the API documentation yaml files.

This is the code that is generated with `transformSchemaName` set to
`pascalCase`.

```ts
export type Assignees = z.infer<typeof Assignees>;
export const Assignees = z.array(...)
```

For now `transformSchemaName` only supports `pascalCase` but it can be
extended in the future.

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Michael Olorunnisola <michael.olorunnisola@elastic.co>
## Summary

Closes elastic#250457
Closes elastic#250460


### Checklist

Check the PR satisfies following conditions. 

Reviewers should verify this PR satisfies this list as well.

- [ ] 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/src/platform/packages/shared/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
- [ ] 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 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
- [ ] 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)
- [ ] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable `backport:*` labels.

### 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.

- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
## Summary

With elastic#245576 in `main` and the
build being green, we have demonstrated the correct behavior for
_existing_ users with existing kibana privileges. This PR now updates
existing test/prebuilt roles to explicitly use these new privileges
moving forward.

## Reference
* Discussion about the benefits/logic for this PR can be found
[here](elastic#232113 (comment)).
* Accompanying `elasticsearch-controller` PR can be found
[here](elastic/elasticsearch-controller#1509).
## Summary

Wanted to add docs for navigation badges and realized we had no dev docs
for Navigation. Added already existing Navigation README to dev_docs and
included a new section for Navigation Badges.

## Testing

Tested it via docs repo:

<img width="1271" height="1068" alt="Screenshot 2026-02-04 at 10 19 57"
src="https://github.com/user-attachments/assets/75e0650c-360d-42b5-863d-ee1f0fe2e189"
/>
…tic#251646)

## Summary

The partition chart schemas (pie, mosaic, treemap, waffle) were nested
under an intermediate `partitionStateSchema` wrapper in
`lensApiStateSchema`. This additional level of nesting caused these
schemas to be omitted from the generated client in the Terraform
provider.

This PR removes the `partitionStateSchema` grouping and adds the
individual chart schemas directly to `lensApiStateSchema`.
elastic#249819)

## Summary

Close elastic#250383
Close elastic#250384

- Init scout in Lens
- Add `switchToEditMode` and `openInLineEditor` to the dashboard app
- Create lens app and add the following methods:
  - `getConvertToEsqlButton`
  - `getConvertToEsqModal` 
  - `getConvertToEsqModalConfirmButton`
- Add `should display ES|QL conversion modal` test

For the test, we have used the LOGSTASH ES archive.

> [!NOTE]
> The complete conversion flow will be tested in a separate PR, once
elastic#248078 is merged.

> [!IMPORTANT]
> The test introduced in this pull request has been skipped until we
introduce a feature flag to hide the feature we want to test:
elastic/kibana-team#2740

### How to run the tests


Run server:
```
node scripts/scout.js start-server --stateful
```

In a separate terminal, run tests:
```
npx playwright test --project local --grep @ess --config x-pack/platform/plugins/shared/lens/test/scout/ui/  --ui
```

## Checklist

- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] [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)
- [x] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable `backport:*` labels.

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
@js-jankisalvi js-jankisalvi requested review from a team as code owners February 9, 2026 09:46
@js-jankisalvi js-jankisalvi requested review from ashokaditya, dhurley14, dplumlee, jeramysoucy, tiansivive and tomsonpl and removed request for a team February 9, 2026 09:46
@js-jankisalvi
Copy link
Copy Markdown
Contributor Author

Closing this PR in favour of #252262. Updated target branch to feature branch connectors-auth-code-grant. Will address open feedback in new PR.

@js-jankisalvi
Copy link
Copy Markdown
Contributor Author

Is this only used to determine if a human controls the creds, to make it easier to identify, to allow them to "refresh" them? That's kinda what I get from the description of the changes, but the top level description says

new authMode attribute for connectors that allows configuring authentication modes as either shared (default) or per-user

After seeing that, I was thinking we'd be maintaining multiple sets of Secrets on a per-user basis, to use when the connector is executed. Except I know we don't really have a concept of "users" like that anyway, so seems unlikely we'd do that.

So, I just wanted to make sure this story doesn't include a multi-Secrets-per-Connector requirement. If so, I wonder if we can change the terms we're using, as I think customer's might get confused. Thinking they could use the same PagerDuty connector with different userids, or similar.

Also, is this mainly just relevant for OAuth stuff? Seems possible. If so, I think that's worth noting in the description ...

Addressed here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport:version Backport to applied version labels Feature:Actions/ConnectorsManagement Issues related to Connectors Management UX release_note:enhancement Team:ResponseOps Platform ResponseOps team (formerly the Cases and Alerting teams) t// v9.4.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[ResponseOps][PerUserAuth] Connector list - authMode attribute in connector saved object and apis