## Summary
Closes https://github.com/elastic/kibana/issues/157203
Closes https://github.com/elastic/kibana/issues/158051
Closes https://github.com/elastic/kibana/issues/158049
With the addition of Per User Dark Mode, components can no longer rely
on `uiSettings` as the source of truth for theme.
CodeEditor fields used to call `uiSettings` to determine if Dark Mode
was enabled, which had been provided in each callers Kibana React
Context.
The new source of truth for theme is the `CoreStart >
ThemeServiceStart`.
Currently, not all callers of CodeEditor provide the `theme` service in
their Kibana Context in a similar way and some callers don't provide it
at all.
This PR updates CodeEditor to get theme values from the Kibana Context
using a new `useKibanaTheme` react hook.
It also attempts audit the callers of CodeEditor to see if their Kibana
Context contains the theme service at the top level (Where I could add
theme to a caller's Context without major changes, I did. Some cases
will require CodeOwner guidance).
The new `useKibanaTheme` react hook will throw a TypeError if theme
isn't found in the top level of the Kibana Context, this will help with
testing as the component will not render. I will remove this after
testing so as not to introduce breaking changes.
## Testing
Please review files for which you are CODEOWNER.
I've attempted to tag all usages of `CodeEditor`/`CodeEditorFIeld` with
a TODO comment with one of the following scenarios:
1) a note where theme was provided already/where I made changes to
provide it in the appropriate context
2) I've asked for CODEOWNER guidance
For scenario 1, please pull and test that CodeEditor locally:
1. Enable Dark Mode from Edit User Profiles by clicking on the Profile
Icon on the top right, and updating your profile.
2. Navigate to the CodeEditors in the plugins you own. If they render
and display in Dark Mode - add a green check to the table below - and
you're done!
3. If it is not rendering, please help me figure out where the theme
service should be provided in the context.
For scenario 2, we will need to figure out where to make changes so your
context is providing theme. Some of the more complex usages may need to
addressed in separate issues.
## Tracking
| Team | Plugin | Theme in Context ? | Verified Working |
| - | - | - | - |
| apm-ui | apm | APM Storybook broken | ? |
| kibana-presentation | presentation_util | Yes. | Yes |
| response-ops | trigger_actions_ui | Yes | Yes |
| response-ops | stack_alerts | Yes | Yes |
| kibana-security | security | Yes | Yes |
| security-defend-workflows | osquery | Yes | Yes |
| kibana-app-services | examples/expression_explorer | Yes | Yes |
| ml-ui | transform | Yes | Yes |
| ml-ui | ml | Yes | Yes |
| uptime | synthetics | Yes | Yes |
| kibana-gis | maps | Yes | Yes |
| kibana-gis | file_upload | Yes | Yes |
| platform-deployment-management | watcher | Yes | [AG] Yes |
| platform-deployment-management | snapshot_restore | Yes | [AG] Yes |
| platform-deployment-management | runtime_fields | Yes | [AG] Yes |
| platform-deployment-management | painless_lab | Yes | [AG] Yes |
| platform-deployment-management | ingest_pipelines | Yes | [AG] Yes |
| platform-deployment-management | index_management | Yes | [AG] Yes |
| platform-deployment-management | grokdebugger | Yes | [AG] Yes |
| platform-deployment-management | es_ui_shared | Yes | [AG] Yes |
| fleet | fleet | Yes | Yes |
| enterprise-search-frontend | enterprise_search | Yes | [AG] Yes |
| kibana-cloud-security-posture | cloud-security-posture | Yes | yes |
| sec-cloudnative-integrations | cloud_defend | Yes | Yes |
| kibana-visualizations/kibana-data-discovery | data | Yes | Yes |
| kibana-visualizations | examples/testing_embedded_lens | Yes | Yes |
| kibana-visualizations | vis_types | Yes | Yes |
| kibana-visualizations | vis_default_editor | Yes | Yes |
| kibana-visualizations | unified_search | Yes | Yes |
| kibana-visualizations | packages/kbn-text-based-editor | Yes | Yes |
| kibana-visualizatons | lens | Yes | Yes|
| kibana-core | saved_objects_management | Yes | Yes |
| kibana-presentation | inspector | Yes | Yes |
| kibana-presentation | canvas | Yes | Yes |
| kibana-data-discovery | discover | Yes | Yes |
| kibana-data-discovery | data_view_management | Yes | Yes |
| kibana-data-discovery | data_view_field_editor | Yes | Yes |
| appex-sharedux | advanced_settings | Yes | Yes |
| enterprise-search-frontend | serverless_search | Yes | [AG] Yes |
| - | - | - | - |
## Unit tests
Currently, many tests are failing since they are probably not providing
`theme` in the context. Once CODEOWNERs have weighed in on CodeEditors
usages that require discussion, I will update the accompanying tests.
## Release note
- Fixes theming of CodeEditors
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Alison Goryachev <alisonmllr20@gmail.com>
Co-authored-by: Dima Arnautov <dmitrii.arnautov@elastic.co>
Co-authored-by: Dima Arnautov <arnautov.dima@gmail.com>
While messing around with time slider control and custom time ranges, I
noticed shouldFetch$ is triggered (turns out search session id is
changing - maybe a separate issue).
During investigation, I found it difficult to explore without unit test
for shouldFetch$.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes the following issues:
1. Suggestions are not reachable by keyboard navigation (it was actually
broken when fixing the [accesibility axe
warning](https://github.com/elastic/kibana/issues/154787), I ran it now
and it doesn't show now)
46c9eb70-4df7-462b-a878-b7d190aaf8c9
2. Dimension removal button is not reachable by keyboard navigation
before:
5011679b-b05a-48ca-a877-bbc940607b56
after:
9d056512-a622-4c1c-aa5b-242e2762e9ae
3. The padding for the reordering groups got a distance between the
empty dimension button (btw I have more little fixes for drag and drop
look but want to submit it in a separate PR to not ping here Discover
team):
<img width="421" alt="Screenshot 2023-07-03 at 17 42 41"
src="a1d22267-07b6-4179-89f9-b4c7ec5da030">
<img width="459" alt="Screenshot 2023-07-03 at 17 39 11"
src="a7b697ca-4ff3-4c18-bf96-a8710615a9df">
4. The focus outline for dataview selector and layer chart selector got
a nicer rectangular shape
before:
<img width="343" alt="Screenshot 2023-07-03 at 10 50 52"
src="0ca305b8-cdbf-4c43-b73d-0058046ab919">
<img width="360" alt="Screenshot 2023-07-03 at 17 41 18"
src="54e61646-5d4e-4512-b6e1-6d758e2b7498">
after:
<img width="350" alt="Screenshot 2023-07-03 at 11 11 01"
src="8ddd81dd-8072-4cf8-a98b-ae5eb9998add">
<img width="415" alt="Screenshot 2023-07-03 at 17 39 51"
src="1c36b3bd-cb15-4cb8-858e-92fc19e3181f">
5. The focus outline was corrected for dimension buttons. I also
refactored code here to make margins, paddings and gaps the property of
the containers and not the items themselves. I think this way it's more
correct.
before:
<img width="418" alt="Screenshot 2023-07-03 at 17 40 54"
src="b8ce4a22-dc69-44a7-8689-70928340ac24">
after:
712e2ac8-f81d-4896-b384-164fc2854766
## Summary
Previously the data plugin relied on the data view plugin to load saved
searches since the saved searches depend upon the data plugin and
circular dependencies needed to be avoided. This is innovative and
perhaps a bit crazy.
What this PR does
- Data view api no longer loads saved searches, removing browser saved
object client usage
- Moves `kibana_context` expression and getKibanaContext function from
data plugin to saved search plugin since it loads saved searches
- Rename data views `SavedObjectsClientCommon` to `PersistenceAPI` -
this is the abstraction around saved object loading that no longer is
exclusive to the saved objects api.
- Adds saved search server api (plugin contract) for loading saved
searches.
- Functional tests on browser and server for kibana_context expression
when loading saved searches
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/158802
We decided that in the case we don't render a Lens suggestion (for
example when we have the SELECT * case) to render the histogram.
**Reminder**: Histogram makes sense only of there is a time field. For
text based mode, time field exists **ONLY** if there is the @timestamp
field.
I don't allow navigation to Lens or open the edit flyout in this case.
When the edit flyout allows the editing of the form based visualizations
(such as histogram) I will enable it then.
FTs have been changed to accomodate this change.
<img width="1751" alt="image"
src="3d28d881-bc60-43de-acf8-8cbcd172a3df">
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Summary
When I created drag and drop for Lens, the API I went for was not the
most readable one. It was designed this way because I wanted to gain
some performance, but it was very hard to maintain the performance gain
with a lot of changes in the drag and drop area because all the pieces
of the code needed to memoized in a tricky way and it wasn't
communicated well.
In the end it works even without these tricks so I decided to simplify
it in this PR.
The main changes include:
1. Instead of multiple `useState` per parameter, we keep all the state
in reducer both for `ReorderProvider` and `RootDragDropProvider`. Thanks
to that we get multiple improvements:
2. The code in `DragDrop` component becomes more descriptive as we don't
run multiple state updates when user executes an action but one state
update describing what actually happens (eg. `dispatchDnd({type:
'selectDropTarget' ....})`. The internal logic of the update lives in
the reducer.
3. We don't have to pass `trackUiCounterEvents` as another prop to
`DragDrop` and run it wherever we need - instead we pass it as a
middleware to the context and run before dispatching (and it's very easy
to add more middlewares if we need extra integrations at some point!)
4. We also run a11y announcements as a middleware instead of inside
`DragDrop` component
5. The `ChildDragDropProvider` props look much cleaner:
before:
```
<ChildDragDropProvider
keyboardMode={keyboardModeState}
setKeyboardMode={setKeyboardModeState}
dragging={draggingState.dragging}
setA11yMessage={setA11yMessage}
setDragging={setDragging}
activeDropTarget={activeDropTargetState}
setActiveDropTarget={setActiveDropTarget}
registerDropTarget={registerDropTarget}
dropTargetsByOrder={dropTargetsByOrderState}
dataTestSubjPrefix={dataTestSubj}
onTrackUICounterEvent={onTrackUICounterEvent}
>
{children}
</ChildDragDropProvider>
```
after:
```
<ChildDragDropProvider value={[state, dispatch]}>{children}</ChildDragDropProvider>
```
6. Created custom hook `useDragDropContext` instead of using
`useContext(DragContext)` and making DragContext private. This way we
will avoid potential problems with using context outside of root.
7. Bonus thing - if we ever decide to move to redux, the structure is
there already
What I am still not happy with is that the tests are very
domain-dependant instead of user-driven - instead of checking the store
actions, I should check the interface from the user perspective. I will
try to work on it once I find some time between more important tasks
though.
## Summary
Run Real Endpoint Cypress E2E on CI using Vagrant
---------
Co-authored-by: Tomasz Ciecierski <ciecierskitomek@gmail.com>
Co-authored-by: Ashokaditya <am.struktr@gmail.com>
## Summary
Running FTR tests locally (not on CI) that make API requests to public
versioned Kibana endpoints is currently broken. This is because:
* we require version headers to be set for both internal and **public**
endpoints in **dev** by way of a runtime check (ensures our code is
locked to a version)
* the vast majority of FTR tests do not set these headers for talking to
public endpoints
* on CI, this is different as we run these tests against a distributable
build (i.e., non-dev)
This manifests locally as a 400 response. E.g. the current
api_integration tests for data views by running:
```
node scripts/functional_test_runner.js --config ./test/api_integration/config.js --grep 'index_pattern_crud'
```
---
There are a few ways to resolve this, this PR proposes that we:
* Keep FTR tests as they are (i.e., don't update all of them to set
headers when making requests to public versioned endpoints), this is a
useful way to exercise our intended end-user behaviour
* Make the version resolution behaviour not depend on `--dev`: rather
set the default resolution to `none` (new setting) when we run in
`--dev` so that it can be configured to behave as we want for tests.
In this way we keep the runtime check for its intended purpose and can
run our FTR tests "as end users" of our endpoints.
---
Close https://github.com/elastic/kibana/issues/161435
The goal is to prevent the following warning and reduce overall CI
times:
```
The following "Jest Integration Tests" config has a duration that exceeds the maximum amount of time desired for a single CI job. This is not an error, and if you don't own this config then you can ignore this warning. If you own this config please split it up ASAP and ask Operations if you have questions about how to do that.
src/core/server/integration_tests/saved_objects/migrations/group3/jest.integration.config.js: 40.7 minutes
```
Source https://buildkite.com/elastic/kibana-pull-request/builds/140963
## Summary
Updated the title for the `enterprise_search` Integration category from
`Enterprise Search` to `Search`
### Screenshots
<img width="1676" alt="image"
src="4f882c01-570c-4117-8689-5caddb7a7de1">
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
EPIC: https://github.com/elastic/kibana/issues/144943
## Summary
Update Events/alerts table to provide `CellActions` with a complete
`FieldSpec`object from DataView
### Affected pages:
* Alerts page
* Security Dashboards
* Rule preview
* Host events
* Users events
### How to test it
Use CellActions on one of the affected pages.
### 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>
## Summary
Fix a bug that was causing the cluster to fall into an unrecoverable
state if an error occurs during the document migration phase of a `v2`
to `zdt` migration (first zdt migration to take over the `v2`
algorithm).
When an error occurs during the document migration phase, the index gets
in a state where `mappingVersions` is present but not `docVersions`, and
the algorithm wasn't able to understand what this state was, and
considered it to just be a plain `zdt` predecessors, which caused an
error when entering the document migration phase, as `docVersions`
couldn't be found.
This PR addresses this, by properly identifying this specific state, and
acting accordingly (by initiating a document migration without checking
for the versions in `docVersions`, as we do then coming from a plain v2
algo)
## Summary
Related to https://github.com/elastic/kibana/issues/150296
- Add the following SO model version change types:
- `data_removal`
- `unsafe_transform`
- Change the existing `data_backfill` type to something less permissive
- Update the tsdoc and documentation accordingly
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/161310
Issue caused by `setState` call after async action without checking that
component is still mounted. Resolved issue by checking component is
mounted after any async action or subscription.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/160052
This PR adds support for the header banner in serverless projects.
<img width="1437" alt="image"
src="c950bbe7-46bb-4b82-b9ee-406aef7748dc">
**NOTE:** This PR adds support for the header banner by applying the
same techniques as in the "classic" layout: special class names of
`header__bar`/`header_firstBar`/`header__secondBar`. The effect is the
"header action menu" bar, which is an optional 2nd bar in the chrome
header, works better after this change when it is always visible. This
is a temporary issue that unblocks the header banner, and fixes other
overlapping issues with the current project layout stylings.
_As followup work_, the @elastic/appex-sharedux team will investigate
converting the Kibana page template to the new
[EuiPageTemplate](https://elastic.github.io/eui/#/templates/page-template/examples)
which supports horizontal sections of a page that have dynamic height --
we need this for the dynamic presence of the header banner, and the
intended dynamic presence of the header action menu.
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
## Summary
Managing large number of saved objects can be cumbersome. This api
endpoint allows the management of references without clicking through a
lot of different UIs.
For example -
This swaps all data view id `abcd-efg` references to `xyz-123`
```
POST /api/data_views/swap_references
{
"from_id" : "abcd-efg",
"to_id" : "xyz-123",
"preview" : false, // optional, necessary to save changes
"delete" : true // optional, removes data view which is no longer referenced
}
returns
{
preview: false,
result: [{ id: "123", type: "visualization" }],
deleteSuccess: true
}
```
Additional params -
```
from_type: string - specify the saved object type. Default is `index-pattern` for data view
for_id: string | string[] - limit the affected saved objects to one or more by id
for_type: string - limit the affected saved objects by type
```
Closes https://github.com/elastic/kibana/issues/153806
## Summary
Closes https://github.com/elastic/kibana/issues/158986
This PR is applying a very simple fix on the unified search bar. It
makes the dataview to not be required to load the text area.
The dataview(s) is required for the suggestions but not for running a
query.
There is currently a bug
https://github.com/elastic/kibana/issues/158986#issuecomment-1620099640
on the apm side. It is happening because the url update is not allowed
when the dataview is not set. This needs to be fixed on the apm side so
I synced with the apm team and they are going to take it.
Add multiple formats for geo_point fields and make geo conversion tools
part of field_format/common/utils
This is needed because various users need locations displayed in
different formats. It would be problematic to allow users to change the
index field formatting for everyone.
WKT and LL where already formatters availible.
I added MGRS and DMS.
## Summary
Summarize your PR. If it involves visual changes include a screenshot or
gif.
### 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: Sean Sullivan <ssullivan@spectric.com>
Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
## Summary
Close https://github.com/elastic/kibana/issues/160207.
Adds a new, additional mechanism for negotiating version (via query
parameter). This is specifically intended to enable Kibana versioned
endpoints to be usable in browser environments where setting a header is
not always possible (like in an `img` tag's `href`).
Note: the header-based version still takes precedence if present.
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Summary
Under some circumstances passing `override` to `POST
/api/data_views/data_view` would fail. Its now fixed.
To test - Try using the override param from the Kibana dev console. I
found it reproduced the problem before the fix and shows its resolved
after the fix. The problem did not appear in the integration tests.
I suspect the problem had to do with how quickly the delete was
performed - if it completed before the create command then everything
was fine. If it didn't then the error would appear. Passing the
overwrite param to the saved object client eliminates the possibility of
the delete failing to complete.
Closes https://github.com/elastic/kibana/issues/161016
- Closes https://github.com/elastic/kibana/issues/156556
- Probably also addresses
https://github.com/elastic/kibana/issues/157239
## Summary
This PR allows to refresh fields list when revisiting Discover page.
## For testing
1. Open discover
2. In a separate tab open Dev Tools and create documents which include
new field names
3. Press "Refresh" in the unified search bar on Discover and notice that
new fields appear under Unmapped section
4. Navigate to another Kibana app (for example Home page)
5. Navigate back to Discover and notice that new fields are now under
Available section and have a proper icon.
## Summary
Fix https://github.com/elastic/kibana/issues/156803
Use `apm.captureError` to properly capture errors thrown by the route
handler (as those errors are then converted to generic 500 errors before
being returned by the server to avoid leaking internal info)
Tackles https://github.com/elastic/kibana/issues/157510
Nothing's wrong with the test, it's only that it's a bit costly, as it
migrates a 100k SO archive.
This PR simply increases the timeout for the conflicting test.
