Fixes https://github.com/elastic/kibana/issues/172500
PR resolves the issue by not re-throwing errors in GeoJsonVectorLayer
and MvtVectorLayer syncData methods. Error state is stored in data
request and displayed to users. Errors are thrown to stop the flow of
execution for syncData.
## Summary
Fixes https://github.com/elastic/kibana/issues/171509 (fixed in all the
places in maps)
Adds middle truncation and combobox auto-expansion to the content to
approximate of 60 character maximum for `SingleFieldSelect` and
`FieldSelect` components in maps.
I removed custom `renderOption` prop so the combobox can take care of
the proper truncation while searching through the fields. One case I had
to hack was to display a tooltip for a disabled state. I used `prepend`
and some custom styling to do so - it works as before (check out the
screenshot below).
<details>
<summary> FieldSelect component before</summary>
<img width="471" alt="Screenshot 2023-11-22 at 16 08 21"
src="eb8a682a-0dfe-4bb0-9a88-8dc5863a5aff">
</details>
<details>
<summary> FieldSelect component after</summary>
<img width="582" alt="Screenshot 2023-11-22 at 16 10 02"
src="b840fb7e-0789-46b7-b783-8e0aadb270ac">
</details>
<details>
<summary> SingleFieldSelect component before</summary>
<img width="430" alt="Screenshot 2023-11-23 at 10 23 15"
src="fc4af30c-32ad-40d8-a051-4b123be8aa54">
</details>
<details>
<summary> SingleFieldSelect component after</summary>
<img width="576" alt="Screenshot 2023-11-22 at 16 32 43"
src="2c3f496e-2e1b-4cf9-aa5b-f38c7a7eace2">
#### disabled state
<img width="829" alt="Screenshot 2023-11-22 at 17 10 48"
src="8db0b076-d3f5-4ec4-9e7c-0e7121b14e04">
</details>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/172013
PR updates TileStatusTracker to clear tile error cache when layer is not
tiled.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/170656
PR adds exists filter to ensure geo field exists
### Test instructions
1. In console, run:
```
PUT geo1
{}
PUT geo1/_mapping
{
"properties": {
"location": {
"type": "geo_point"
}
}
}
PUT geo1/_doc/1
{
"location": "25,25"
}
PUT geo2
{}
PUT geo2/_doc/1
{}
```
2. Create `geo*` data view
3. create new map
4. add documents layer from `geo*` data view.
5. Add heatmap layer from `geo*` data view.
6. Verify geo1 data is displayed and warning is not displayed fro geo2
shard failures
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/162840
## Summary
This PR adds a visualization alias for the new Links embeddable so that
all Links library items can be managed/edited from the Visualization
library, like so:
8541506b-cfdd-4a2f-8bc2-841220def7a3
However, in order to get the above working, it was unfortunately not as
simple as just adding a visualization alias. Because the Links
embeddable does not have a dedicated editing app (all editing/creation
is done through a flyout), the usual `aliasPath` + `aliasApp` redirect
that happens for editing an alias did not work in this case.
To get around this, I've had to make changes to how aliases are
registered, as well as both the Visualization `VisualizeListing`
component and the generic `TableListViewTableComp` content management
component:
- **Summary of visualization alias changes:**
First off, I made changes to the typing of aliases - specifically,
rather than taking two independent `aliasPath` and `aliasApp` props,
I've combined them into a singular `alias` prop which will either be of
type `{ alias: string; path: string; }` or `{ embeddableType: string;
}`. This makes it easier to determine (a) whether a visualization is of
type `BaseVisType` or `VisTypeAlias` and (b) if it **is** of type
`VisTypeAlias`, how the editing of that vis should be handled.
Specifically, if `alias` is of type `{ alias: string; path: string; }`,
then it is a normal visualization and behaviour should be the same as it
was previously; however, if it is of type `{ embeddableType: string; }`,
then this is an **inline** alias - i.e. editing should be done inline
via the embeddable factory's edit method.
- **Summary of `VisualizeListing` changes**
The primary changes here were made to the `editItem` callback -
specifically, if the fetched saved object has neither an `editApp` nor
an `editUrl`, then it will now try to fetch the embeddable factory for
the given saved object type and, if this factory exists, it will call
the `getExplicitInput` method in order to handle editing.
- **Summary of `TableListViewTableComp` changes**
Previously, an error would be thrown if both a `getDetailViewLink` and
an `onClickTitle` prop were provided - while I understand the original
reasoning for adding this catch, this no longer works if we want to
support inline editing like this. In this case, I needed **only** the
Link embeddable items to have an `onClick` while keeping the behaviour
for other visualizations the same (i.e. all other visualization types
should continue to link off to their specific editor apps) - however,
since this method is not provided **per item**, I had no way of making
an exception for just one specific item type.
Therefore, to get around this, it is now considered to be valid for
**both** the `getDetailViewLink` and `onClickTitle` props to be defined
for the `TableListViewTableComp` component. In order to prevent conflict
between the two props, I have made it so that, if both are provided,
`getDetailViewLink` **always takes precedence** over `onClickTitle` - in
this case, `onClickTitle` will **only** be called if `getDetailViewLink`
returns `undefined` for a given item. I have added a comment to
hopefully make this clear for consumers.
### 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] 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)
### 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/170272
The cause of the problem is that Maps is not setting
[_mvt](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-vector-tile-api.html)
`size` parameter.
Lets illustrate the problem with an example.
* index.max_result_window is set to 20,000.
* There are 15,000 hits matching the query for the tile, but because
`size` is not provided, the tile returns the default size value of
10,000 hits.
* Tile request sets `track_total_hits` to 20,001. Tile meta returns
`"hits.total.relation": "eq"` and `"hits.total.value": 15000`
properties, indicating that all possible hits are returned in the tile.
* Maps UI does not display "incomplete results" even though 5000 hits
are not contained in the tile.
* This happens because `hits.total` properties from tile meta is used to
indicate "incomplete results" and the returned value indicates that all
results are contained in the tile. We know this is not true because the
tile actually only returned 10,000 hits and not all 15,000 matching
hits. Thus, without setting `size`, the tile is not returning all of the
hits indicated by `track_total_hits`.
### test instructions
1. install web logs sample data set
2. In dev tools, run the following
```
POST kibana_sample_data_logs/_doc/
{
"geo": {
"coordinates": "59,-106.5"
},
"@timestamp": "2023-08-01"
}
PUT /kibana_sample_data_logs/_settings
{
"index" : {
"max_result_window" : 20000
}
}
```
3. Create new map
4. Set time range to `1 year ago to 1 year from now` to display all web
logs data
5. add documents layer. Verify point circled in image is displayed.
Without changes, this point would not be returned in the tile because
the tile would only return the first 10000 matches.
<img width="500" alt="Screenshot 2023-11-15 at 11 31 25 AM"
src="2249d571-24c4-41ad-975e-d44ee6d246ce">
Closes https://github.com/elastic/kibana/issues/170983
### Test instructions
1. Download world countries geojson from
https://maps.elastic.co/v8.12/index.html?locale=en#file/world_countries
2. upload downloaded world countries
3. create new map
4. add "Choropleth" layer
5. Set boundaries source to "Points, lines, and polygons from
elasticsearch". Select world countries data view. Set join field to
"iso2"
6. Set statistics view to kibana sample web logs. Set join field to
"geo.src"
7. minimize layer TOC
8. save map and re-open.
9. Minimized layer legend icon should stop showing loading state once
EMS base map is loaded
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/170911
root problem is that `EuiButton*` components are disabled when passed
`isLoading` property. Re-worked component to not pass `isLoading` to
`EuiButton*`
### Test instructions
1. create new map
2. click "Collapse layers panel" to collapse layer control
3. open browser dev tools. Open network tab and select "Slow 3G"
4. Pan and zoom map to cause basemap tiles to load. "Expand layers
panel" button should be clickable during loading
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/169545
Closes https://github.com/elastic/kibana/issues/170657
While investigating https://github.com/elastic/kibana/issues/169545, it
was determined that Maps current error handling leaves a lot to be
desired. This PR cleans up several problems at once since they are all
intertwined.
#### Problem 1 - layer error removed when another data request finished
Redux store contains error state in a single location, `__errorMessage`
key in `LayerDescriptor`. This resulted in other operations, like
"fitting to bounds", "fetching supports feature state", or "fetching
style meta" clearing layer error state.
#### Solution to problem 1
Redux store updated to contain isolated error state
1) `error` key added `DataRequestDescriptor`, allowing each data request
to store independent error state. This will capture data fetching errors
when fetching features and join metrics.
2) `error` key added to `JoinDescriptor`, allowing each join to store
independent error state. This will capture join errors like mismatched
join keys
3) `__tileErrors` added to `LayerDescriptor`, allowing each tile error
to be stored independently. This will capture tile fetch errors.
#### Problem 2 - tile status tracker clears error cache when map center
tile changes
This resulted in removing tile errors that may still be relevant if
tiles have not been refetched.
#### Solution to problem 2
Updated tile status tracker to only clear a tile error when the tile is
reloaded.
#### Problem 3 - Tile Errors do not surface elasticsearch ErrorCause
This results in useless error messages like in the screen shot below
<img width="300" alt="Screenshot 2023-11-01 at 2 39 01 PM"
src="75546228-24c6-4855-bea7-39ed421ee3f4">
#### Solution to problem 3
Updated tile status tracker to read and persist elasticsearch ErrorCause
from tile error. Now tile error messages contain more relevant
information about the problem.
<img width="200" alt="Screenshot 2023-11-03 at 9 56 41 AM"
src="b9ddff98-049e-4f22-8249-3f5988fa93a5">
#### Problem 4 - error UI is not interactive when layer editor is not
available, in dashboards or read only user
#### Solution to problem 4
* Updated layer tooltip to only display error title
<img width="200" alt="Screenshot 2023-11-03 at 11 22 50 AM"
src="6943aead-a7d6-4da3-8ecc-bb6065e0406a">
* Moved error callout from editor to legend so its visible when map is
in dashboard and by readonly users.
<img width="200" alt="Screenshot 2023-11-03 at 11 23 45 AM"
src="358fe133-4c5a-4f06-a03e-e96a16b7afb6">
Moving error details from tooltip to legend allowed error details to
contain interactive elements. For example, display a tile picker so that
users can see each tile's error. This will be useful in the future where
search source requests can display "view details" button that opens
request in inspector.
#### Problem 5 - error UI displayed as warning
This results in inconsistent view between kibana applications
#### Solution to problem 5
Updated error UI to use danger callout and error icon
### test instructions
1) install sample web logs
2) create map
3) add documents layer with vector tiles scaling
4) add documents layer with geojson scaling
5) add join layer
6) add filter
```
{
"error_query": {
"indices": [
{
"error_type": "exception",
"message": "local shard failure message 123",
"name": "kibana_sample_data_logs"
}
]
}
}
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/170042
PR disables vector tile adapter when map does not contain vector tile
layers
### Test
1) create new map
2) add documents layer
3) set scaling to "limit to 10000"
4) open inspector. Notice inspector only displays request adapter
5) change scaling to "vector tiles"
6) open inspector. Notice inspector displays vector tile adapter and
request adapter
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Close https://github.com/elastic/kibana/issues/167152
Log a warning instead of throwing an error in
`saved_object_content_storage` when response validation failed.
We decided to do this as a precaution and as a follow up to an issue
found in saved search https://github.com/elastic/kibana/pull/166886
where storage started failing because of too strict validation.
As of this PR the saved_object_content_storage covers and this change
cover:
- `search`
- `index_pattern`
- `dashboard`
- `lens`
- `maps`
For other types we agreed with @dej611 that instead of applying the same
change for other types (visualization, graph, annotation) the team would
look into migrating their types to also use
`saved_object_content_storage`
https://github.com/elastic/kibana/issues/167421
## Summary
Fix#163246
This PR fixes the CM problems within the Visualize List page leveraging
the services already in place.
The approach here is lighter than #165292 as it passes each client via
the TypesService already used to register extensions in the
Visualization scope. Also the `search` method now transparently uses the
`mSearch` if more content types are detected without leaking any
implementation detail outside the `VisualizationClient` interface.
More fixes/features:
* fixed Maps update operation definition which was missing the
`overwrite` flag
* Allow `mSearch` to accept an options object argument
* Added new helper functions to interact with the metadata flyout in
Listing page
### 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: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Closes https://github.com/elastic/kibana/issues/165974
The root cause of the problem is calling `basePath.prepend` on a path
without a leading `/`. Maps is not consistent with path constants. Some
have leading `/` while others do not. To resolve the issue, this PR
updates all path constants to consistently have leading `/`.
PR adds functional test runner with `map.includeElasticMapsService:
false` to ensure maps is tested without EMS enabled to catch future
regressions.
### Test instructions
* set *map.includeElasticMapsService: false* in kibana.dev.yml
* install sample data set
* create new map with documents layer
* Configure label styling
* Verify layer is displayed with labels
<img width="500" alt="Screen Shot 2023-09-13 at 6 26 23 AM"
src="44d12e87-9b80-424c-9bc9-126b373bdf18">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
closes https://github.com/elastic/kibana/issues/165366
closes https://github.com/elastic/kibana/issues/165367
close https://github.com/elastic/kibana/issues/165697
replaces https://github.com/elastic/kibana/pull/165337
Serverless elasticsearch does not support index setting
`number_of_shards`
PR resolves issue be removing `number_of_shards`. When
`number_of_shards` was introduced way back when, the default value was
5. Now the default value is one. Therefore there is no point providing
the setting since its the same as the default. Just removing so code
works across both serverless and traditional deployments
PR also cleans up some types that are duplicative of elasticsearch types
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
Fixes https://github.com/elastic/kibana/issues/165183
### Test instructions
1) install any sample data set
2) open new dashboard
3) Use "Add panel" buttons to add by-value map with only base map layer
4) Ensure map tiles fill entire map panel in dashboard
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
There's a few EUI imports out there that folks are reaching into
`@elastic/eui/lib/` for (which doesn't contain any types - something I'm
looking into separately) that could instead be imported at the top
`@elastic/eui` level, which is properly typed.
### Checklist
N/A - types only
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
`85.1.0` ➡️ `86.0.0`
⚠️ The biggest change in this PR is migrating the `react-beautiful-dnd`
dependency to it's open-source forked successor, `@hello-pangea/dnd`.
This new fork has better typescript support and additionally supports
both React 17 and React 18.
## [`86.0.0`](https://github.com/elastic/eui/tree/v86.0.0)
- Added React 18 support (StrictMode not yet supported).
([#7012](https://github.com/elastic/eui/pull/7012))
**Deprecations**
- Deprecated `euiPaletteComplimentary`; Use `euiPaletteComplementary`
instead. ([#6992](https://github.com/elastic/eui/pull/6992))
**Breaking changes**
- Replaced the underlying drag-and-drop library from
`react-beautiful-dnd` to its fork `@hello-pangea/dnd`
([#7012](https://github.com/elastic/eui/pull/7012))
([#7012](https://github.com/elastic/eui/pull/7012))
- No code updates are needed if using only `<EuiDragDropContext>`,
`<EuiDroppable>` and `<EuiDraggable>` with no direct imports from
`react-beautiful-dnd`. In case you were importing things from
`react-beautiful-dnd` and using them together with EUI components, you
need to switch to `@hello-pangea/dnd` which has cross-compatible API.
---------
Co-authored-by: Tomasz Kajtoch <tomasz.kajtoch@elastic.co>
Co-authored-by: Tomasz Kajtoch <tomek@kajto.ch>
Co-authored-by: Cee Chen <549407+cee-chen@users.noreply.github.com>
Co-authored-by: Drew Tate <andrew.tate@elastic.co>
## Summary
Partially address https://github.com/elastic/kibana/issues/163337 for
lens, visualize, maps
### Context:
In serverless navigation, we changed how breadcrumbs work. Instead of
setting the full path manually, we automatically calculate the main
parts of the path from the side nav + current URL. This was done to keep
side nav and breadcrumbs in sync as much as possible and solve
consistency issues with breadcrumbs across apps.
https://docs.elastic.dev/kibana-dev-docs/serverless-project-navigation#breadcrumbs
Apps can append custom deeper context using the
`serverless.setBreadcrumbs` API. Regular `core.chrome.setBreadcrumbs`
has no effect when the serverless nav is rendered.
### Fix
This PR fixes lens, visualize, and maps to add "title" breadcrumb in
serverless. **Unfortunately, it doesn't fully restore the full
breadcrumbs functionality visualize/maps/lens have in the non-serverless
Kibana:**
In the non-serverless Kibana lens/visualize/maps have sophisticated
breadcrumbs where context takes into account `ByValue` and
`originatingApp` and can switch depending on the context. For example,
if the user is coming from "Dashboard" to edit "byValue" Lens
visualization, Lens breadcrumbs display "Dashboard > Create", instead of
"Visualization > Create".
Currently, we can't repeat this behavior with serverless breadcrumbs
because the context is set by the navigation config, e.g.:
9538fab090/x-pack/plugins/serverless_observability/public/components/side_navigation/index.tsx (L136-L141)
In this PR I attempt to do a quick fix for the serverless breadcrumbs by
simply appending the last ("title") part of the breadcrumb. In a follow
up we need to think about how to bring back the original breadcrumbs
functionality with changing `Visualize <-> Dashboard` context. We also
will need to figure out how to sync the changing context with the side
nav, as we don't want to show "Dashboard" in the breadcrumb, but have
"Visualization" highlighted in the side nav. Here is the issue:
https://github.com/elastic/kibana/issues/163488
Part of https://github.com/elastic/kibana/issues/162069
> This happens in maps too and possibly other SOs that have null
description (not sure if it were ever possible to have null description
in maps.) It seems from the SOs that Bhavya sent that it was possible
for visualizations. With this schema change the bug if fixed
https://github.com/elastic/kibana/pull/162106
> Not sure if it makes sense to also do it in maps. @nreese wdyt?
Add support for null description in maps saved object to be consistent
with visualize saved objects.
### test instructions
1) Install web logs sample data set
2) export map
3) manually change ndjson, changing `description:""` to
`description:null`
4) reimport map saved object
5) verify map can be opened
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/141978
<img width="600" alt="Screen Shot 2023-07-12 at 1 51 45 PM"
src="a71fc82f-31e0-49b2-9178-c70d890a9912">
### Test instructions
* clone https://github.com/thomasneirynck/faketracks
* cd into `faketracks`
* run `npm install`
* run `node ./generate_tracks.js --isTimeSeries`
* In Kibana, create `tracks` data view
* In Maps, create new map and add `Top hits` layer. Select `Tracks` data
view.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The NativeRenderer component is currently used to mount another
component in a separate mounting point. As far as I recall, we
introduced <NativeRenderer/> to allow users to create visualizations in
non-React frameworks. The idea was that users could write their own Lens
visualizations or datasources code and integrate it with our system.
However, it seems that this concept hasn't gained traction and we don’t
have it prioritized. Even if users express interest in writing their
visualizations outside of React, it is still possible to do so with some
additional boilerplate code (which we could provide as an example
non-React visualization).
Pros:
1. Simplifies and shortens the code:
1.1. Testing and debugging become easier as we no longer need to check
separate React trees when integrating frame, data source, and
visualization components.
1.2. Components communicate using standard React patterns, making
maintenance and comprehension simpler.
1.3. Context providers no longer need to be passed to each separate
component since they are already within the context.
1.4. Easier propagation of events or any other form of inter-component
communication.
2. Greatly improves performance and facilitates maintenance:
2.1. Directly accessing context inside the DatasourcePanel eliminates
the need for context passing, resulting in better performance.
2.2. Removing the requirement for a separate React root also contributes
to improved performance.
3. The render method will be removed when we upgrade to React 18. While
we could replace it with the new createRoot method, it makes sense to
perform some cleanup ;)
Cons:
1. Setting up non-React visualization or data source code might become
slightly more complex.
Performance improvement for drag and drop action with these changes:
before:
<img width="1110" alt="Screenshot 2023-07-10 at 07 14 39"
src="45a1b09b-5189-46f5-af2b-7781fcf4e774">
after:
<img width="1117" alt="Screenshot 2023-07-10 at 07 16 24"
src="0e704da1-3220-4eb9-8fa0-cc3584a90090">
## Single render when dragging:
(the first image is 3 screenshots from 3 different react roots as they
have separate mounting point. The complete render time is ~380ms)
<img width="1117" alt="Screenshot 2023-07-10 at 07 16 24"
src="6d7f2d9f-a758-476e-8efb-38693ae90097">
After we have one common render tree. Because we don't have to pass
context down as a prop, we greatly reduced the number of components
rerendered. (I will be working on reducing the render time for workspace
panel as this seems to still be a bottleneck point)
<img width="732" alt="Screenshot 2023-07-10 at 14 52 41"
src="03ec97b3-8225-490e-8884-0fd4e69587e8">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
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>
Part of https://github.com/elastic/kibana/issues/141978
PR updates tracks layer with "group by time series" logic. When true,
geo_line metric aggregation is proceeded by `time_series` bucket
aggregation instead of `filters` bucket aggregation (used by existing
terms split).
### UI when creating tracks layer with time series data view
<img width="481" alt="Screen Shot 2023-06-22 at 12 35 46 PM"
src="ccfeb6ef-c714-49a3-a6d6-f6b52cce80be">
<img width="469" alt="Screen Shot 2023-06-22 at 12 35 55 PM"
src="55cba2dc-6326-4141-bde5-7a6cc0f0b333">
<img width="542" alt="Screen Shot 2023-06-22 at 12 49 22 PM"
src="694ce621-2b6e-4a20-ba20-b9f9d20da8ef">
### UI when editing tracks layer with time series data view
<img width="447" alt="Screen Shot 2023-06-22 at 12 36 17 PM"
src="96cbb3f3-4ca5-430f-91b3-71b5013ca6e9">
<img width="457" alt="Screen Shot 2023-06-22 at 12 36 24 PM"
src="4d603809-7e6a-4b72-98d7-d3a516b2c809">
### Test instructions
* clone https://github.com/thomasneirynck/faketracks
* cd into `faketracks`
* run `npm install`
* run `node ./generate_tracks.js --isTimeSeries`
* In Kibana, create `tracks` data view
* In Maps, create new map and add `Tracks` layer. Select `Tracks` data
view.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
`IVectorSource` interface has many similar sounding methods that are
used for different purposes. These lead to confusion and an unclear API
* getFieldNames
* getFields
* getFieldByName
Although `getFieldNames` sounds similar to `getFields`, the 2 are used
for very different purposes.
* getFieldNames returns a string array that is used to trigger source
re-fetch
* getFields returns an array of fields to drive UI such as field
selection for data driven styling
`getFieldNames` overlaps 100% in functionality with `getSyncMeta` and is
not needed. Combining output of `getFieldNames` into `getSyncMeta`
simplifies the `IVectorSource` API and removes some confusion.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Why?
To simplify the process of migration to react-router@6.
https://github.com/remix-run/react-router/discussions/8753
What problems exactly it solves?
- In my previous PR I added `CompatRouter`
https://github.com/elastic/kibana/pull/159173, which caused changes in
~50 files and pinged 15 Teams. And this is just meant to be a temporary
change, so when we're done with the migration I would have to revert
these changes and engage everyone to review the PR again. And it is just
a single step in the migration strategy. So to make our lives easier I
think it would be better to have a common place where we do import our
router components because it will allow us to surface some extra logic
in single place instead of going through the whole source code again.
- `react-router@6` doesn't support a custom `Route` component, so that
means our custom `Route` component that we're using almost everywhere
today, will need to be replaced by a different solution. I have decided
to add `Routes` component, which will be responsible for rendering the
proper component (`react-router@6` renamed `Switch` to `Routes`, so I
have named this component to align with the dictionary of the new
router) and also is going to add the logic that today is done in `Route`
(moving logic to `Routes` will be done in the follow-up PR, here I just
wanted to focus on using the common router components to make the review
process easier)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
closes https://github.com/elastic/kibana/issues/158857
PR resolves issue by adding `isVisible` and `showAtZoomLevel` checks
into `isLayerLoading` and returning false if a layer is not visible (and
therefore, would not load data).
PR also increases test coverage to help ensure regression is not
re-introduced.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
closes https://github.com/elastic/kibana/issues/159408
PR consolidates source registry into a single file to ensure that all
sources are registered when only map embeddable is loaded. To prevent
regression, unit test added to ensure that all SOURCE_TYPES enum values
are contained in registry.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related issue: https://github.com/elastic/kibana/issues/148665
This PR adds a link to the anomaly explorer for the job corresponding to
the anomalies layer in maps. The link is found under 'Source details'
once the anomalies layer is created.
<img width="1291" alt="image"
src="f109ce21-1aec-40c4-8cf1-fc3dedaef199">
## NOTE
This is dependent on the changes in maps
https://github.com/elastic/kibana/pull/159255
### Checklist
Delete any items that are not applicable to this PR.
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
https://github.com/elastic/kibana/pull/159161 is adding adding hyperlink
to anomaly explorer for job from anomaly layer in maps. A requirement
from this request is to be able to include timerange and query state in
the hyperlink. This PR updates ISource.getImmutableProperties to take
dataFilters parameter so hyperlink can be updated with latest query
state.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/158133
Sources where not getting removed because `return` was used instead of
`continue` in `for...in` loop. This caused the function to return
instead of processing remaining sources.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
