[Maps] Added options to disable zoom, hide tool tips, widgets/overlays in embeddable maps

[shahzad31]

Fixes: #49871

Summary

To achieve the skimmed down version to be used in Uptime app,
Following configurable options are added into embeddable maps API

1. Disable Double click zooming
2. Disable zoom(hide zoom control)
3. Hide widget overlays
4. Hide Panel header

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-gis (Team:Geo)

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: 47b971b

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: 923bba2

[nreese]

Thanks for opening a PR for #49871

Users can still zoom in by holding shift and dragging over an area. You may want to set interactive: false when initializing the map.

This PR introduces a lot of variables for the embeddable input:

• disableZoom
• disableTooltipControl
• hideToolbarOverlay
• hideWidgetOverlay

How about simplifying them into a single key, isNonInteractiveMap. When true, then the UI will hide all chrome, disable tooltips, and disable map interactions. How does that sound? So keep redux actions and selectors, but trigger from single embeddable input.

@thomasneirynck This PR hides attribution. Is that a good idea? I think attribution should never be allowed to be hidden. For uptime, none of the sources have attribution so it should not matter but I think there are legal requirements to show attribution for EMS layers using OSM data.

[nreese]

The more I think about, maybe the redux state should be simplified as well and only have a single boolean isNonInteractiveMap. GisMap should get its state from redux connectors since its a connected component instead of passing state into the component with props. addFilters and renderTooltipContent are passed in as props because there are functions and can not be stored in redux state.

[shahzad31]

@nreese i agree about simplifying redux state, though about first point, or accumulating all booleans into single booleans, i also thought of it.

Why i opted for keeping all options separate to keep it more flexible, if different needs arises, i mean if someone wants to keep some toolbar or widget , or zooming. They can individually disable/enable those.

Combining them will keep code clean, but it won't be as flexible. Maybe we can have a one redux action to pass whole object, something like
mapOptions = {zoom: false, tooltip:false, etc }
but that also doesn't look clean.

Though just having isNonInteractiveMap does looks way more clean.

WDYT?

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: fa948dd

[justinkambic]

Why i opted for keeping all options separate to keep it more flexible

FWIW I'm +1 for flexibility too, combining the boolean flags seems like something a future consumer could run up against and want to change: "I want to enable tooltips but disable zooming".

[bcamper]

I agree having some level of granularity over controls (zoom, pan, tooltips, legend etc.) makes sense.

As for attribution: generally, it's going to be required that we show it somewhere, but it does not necessarily need to be on the map itself, e.g. it could be nearby on the page, or sometimes apps that have other non-map components will group all attribution together in a single "Data sources" link. But, there's nuance there and concern that a client from another group wouldn't know the requirements, so we may want to be more conservative and not allow it to be disabled for now, wait and see if it comes up in practice.

[justinkambic]

we may want to be more conservative and not allow it to be disabled for now, wait and see if it comes up in practice.

👍

[shahzad31]

@thomasneirynck This PR hides attribution. Is that a good idea? I think attribution should never be allowed to be hidden. For uptime, none of the sources have attribution so it should not matter but I think there are legal requirements to show attribution for EMS layers using OSM data.

@nreese @bcamper i don't understand the attribution part, i think

attributionControl: false,

was already there, i haven't changed that.

[nreese]

i don't understand the attribution part

This line in {!this.props.hideWidgetOverlay && <WidgetOverlay />} gis_map/view.js

hideWidgetOverlay should not hide the entire WidgetOverlay, just LayerControl and ViewControl portions but AttributionControl should always be visible and not be allowed to be turned off.

[shahzad31]

@nreese i have removed the option to hide attribution, i think we can keep widgetOverlay, it shouldn't be a problem. I have also refactored redux state and have moved all props to redux.

Have also consolidated zooming control and options into interactive bool.

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: b4cb029

[nreese]

Thanks for all of the changes. This is looking really nice.

Could you please add the new map embeddable input parameters to https://github.com/elastic/kibana/blob/master/x-pack/legacy/plugins/maps/public/embeddable/README.md

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: ddb49c1

[nreese]

Thanks for making these changes.

LGTM with green CI

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: 184a7e1

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: 6b68572

[nreese]

@elasticmachine merge upstream

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: e0ed451