-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Lens] Ability to share a visualization link from Lens #75316
Comments
Pinging @elastic/kibana-app (Team:KibanaApp) |
@AlonaNadler Questions for you:
|
Yes, when sharing it should share the visualization with the existing filter, time range, and search bar query
Ideally, users should be able to share without saving. Lens shares the visualization as a snapshot ideally it should work similarly to the way it works in visualize
Not sure I understand the question, can you elaborate, when a visualization is not unsaved how does it matter if it's by value or by reference? |
@AlonaNadler That does clarify the scope you were imagining. Because you've said that snapshot sharing is a requirement, we should implement this in two stages: The first stage would be "Saved object" sharing, which is one of the features in Visualize. This is low effort because we already have most of the URL parameters needed. The second stage of "snapshot sharing" is high effort, probably a multi-week project. We can't even start this until we clean up our state management tech debt, which delays it further. It's pretty closely related to the idea of deep linking into Lens, so once we commit to this we should consider both use cases of public sharing and also deep linking. |
Ran into this use-case today. Starting to utilize more Lens in initial visualization exploration, but I can't directly share a lens-created graph to co-workers. It seems I would need to put the viz on a dashboard and share the dashboard, which seems.. excessive. I tracked the other linked issues and they're all either closed or in a state where they are ready to be closed. Currently, there doesn't seem to be an existing easy way to share a lens graph directly? |
@iankoetter For now the fastest way I can think of to share a Lens vis is the following:
Note that this will add the vis to the "Visualize library" listing |
second, somewhat related use case: you're in the cases markdown editor and you want to define a lens vis without having to save an object first but without having to include all of the complete details of the lens json / saved object |
Hi, Is there a way we can achieve this? Thanks, |
@Sagesh try putting the single lens visualization on a dashboard which gives the ability to suppress the Kibana UI. this should be a good workaround |
Thanks. |
Any updates on this, having to save these to share really slows collaboration. This is the primary reason my team does not use Lens, generally we do an adhoc graph and share it around will troubleshooting. Saving it just creates bloat we would need to clean up later. |
is this planned any time soon? |
@odmby Unfortunately we don't have a fixed release date for this yet - we will definitely consider this feature in our next round of planning for a version not too far down the line. Thanks for expressing your interest here! |
The new URL service #87304 should help with this - it would allow us to store state as part of the short url SO which is not part of the URL itself so we wouldn't need to do RISON parsing to get the snapshot state back. |
+1 #134295 |
I came across a mildly-embarassing situation regarding this feature today. If I try to share a time-locked lens visualization from our (internal) overview cluster I get a link like this https://overview.elastic-cloud.com/app/lens#/edit/557a40d0-3e29-11ed-b9cc-9db10f1626d2?_g=h@037f68b This gives me just the last 15 minutes and throws an error telling me to use the non-existent share functionality. In the end I think this means the only way I can send someone a time-locked link to a lens visualization is to put it in a dashboard. This isn't a terrible situation, but seems like it'd be cleaner to offer "share" on lens the way we do on other viz types. Or maybe I can just re-work my sharing/exploring muscle memory to be dashboard-based now that we have better support for inline viz for dashboards. |
From a users perspective this means there's no obvious way to share a lens visualisation without knowing it's ok to copy the url which in other situations is not recommended. |
## Summary Fixes #75316 * Lens * [x] Refactored Top nav actions code to be more modular * [x] Created new Locator object for Lens * [x] Enabled server side to make Short URL work with it * [x] Added unit tests for it * [x] Extended `getEditPath` to support `filters` and `refreshInterval` * [x] Extended mounting code in Lens to handle a new type of incoming context * [x] Add new Share action * [x] Added new `objectTypeTitle` prop to have custom titles on Share popover * [x] Replaced the `Download CSV` action and move it as menu item * [x] Refactor code into share item provider + (lazy) panel content * [x] Add debug flag to make CSV download testable * [x] Add functional tests for CSV download * [x] Add Permalink action * [x] Integrate Permalink with Short URL service * [x] Tweaked Permalink action to work with SO custom URL * [x] Tweaked Permalink action to handle disabled state * [x] Updated unit tests with new features * [x] Added (basic) caching logic to avoid too many snapshot duplicate Short URLs * [x] New share function test suite created * [x] Extended `browser` service with a new method to have a blank tab in browser * [x] New helper functions in Lens to test Share feature <img width="375" alt="Screenshot 2023-01-11 at 12 58 30" src="https://user-images.githubusercontent.com/924948/211800819-60efe70a-9ebe-4bde-82e0-8fa264e8c4af.png"> <img width="427" alt="Screenshot 2023-01-11 at 12 58 36" src="https://user-images.githubusercontent.com/924948/211800825-ae7b86d0-0e42-4227-a425-cdcd94ec78cb.png"> <img width="426" alt="Screenshot 2023-01-11 at 12 58 40" src="https://user-images.githubusercontent.com/924948/211800827-73bfb773-b30e-495c-aa61-f5fd10f35d31.png"> <img width="428" alt="Screenshot 2023-01-11 at 12 58 46" src="https://user-images.githubusercontent.com/924948/211800830-89539c37-7495-48f0-9de6-b7d6f15b7397.png"> <img width="427" alt="Screenshot 2023-01-11 at 12 59 03" src="https://user-images.githubusercontent.com/924948/211800833-6f1843b9-ab22-49d9-adbd-8f5f588b52e7.png"> ### Notes #### Short URL requirement This feature strictly requires the ShortURL service to be enabled to work, otherwise the permalink feature is disabled for snapshot sharing. This requirement is not clearly stated in the Share menu (yet) like other app do as the Sharing flow had to be customised in Lens due to some other technical challenges. Would it be ok to workout a UI improvement as follow up? #### Context tech debt The way the locator works as injecting the shared state into the context produced a discrete amount of branching, due to inconsistency of the `context` type coming from different sources (Discover, Agg-based/TSVB, Lens itself...). Perhaps it's worth discussing having a refactoring of the context type here? #### Missing locator service Due to the way the sharing logic works in Lens the locator has not been exported from the `plugin` functions. I thought to add a custom function for it, but perhaps we could investigate a bit better whether this is needed and eventually its implementation in a follow up task. ## How is the snapshot URL generated? ```mermaid sequenceDiagram actor User User->>Share Snapshot URL: click Share Snapshot URL->> Lens ShortUrlService: Lens state Lens ShortUrlService->> Lens ShortUrlService: Check cache based on state Lens ShortUrlService->> ShortUrlService: Generate a Short URL ShortUrlService->> Lens ShortUrlService: new Short URL Lens ShortUrlService->> Application `getUrlForApp`: Build absolute URL Application `getUrlForApp`->> Lens ShortUrlService: final URL Lens ShortUrlService->>Share Snapshot URL: final URL Share Snapshot URL->>User: final URL copied in clipboard ``` ### Checklist Delete any items that are not applicable to this PR. - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [ ] [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 - [ ] Any UI touched in this PR is usable by keyboard only (learn more about [keyboard accessibility](https://webaim.org/techniques/keyboard/)) - [ ] 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)) - [ ] 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 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)) - [ ] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers) ### Risk Matrix Delete this section if it is not applicable to this PR. Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release. When forming the risk matrix, consider some of the following examples and how they may potentially impact the change: | Risk | Probability | Severity | Mitigation/Notes | |---------------------------|-------------|----------|-------------------------| | Multiple Spaces—unexpected behavior in non-default Kibana Space. | Low | High | Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces. | | Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks. | High | Low | Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure. | | Code should gracefully handle cases when feature X or plugin Y are disabled. | Medium | High | Unit tests will verify that any feature flag or plugin combination still results in our service operational. | | [See more potential risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) | ### 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: Kaarina Tungseth <[email protected]> Co-authored-by: Stratoula Kalafateli <[email protected]> Co-authored-by: Andrew Tate <[email protected]> Co-authored-by: kibanamachine <[email protected]>
## Summary Fixes elastic#75316 * Lens * [x] Refactored Top nav actions code to be more modular * [x] Created new Locator object for Lens * [x] Enabled server side to make Short URL work with it * [x] Added unit tests for it * [x] Extended `getEditPath` to support `filters` and `refreshInterval` * [x] Extended mounting code in Lens to handle a new type of incoming context * [x] Add new Share action * [x] Added new `objectTypeTitle` prop to have custom titles on Share popover * [x] Replaced the `Download CSV` action and move it as menu item * [x] Refactor code into share item provider + (lazy) panel content * [x] Add debug flag to make CSV download testable * [x] Add functional tests for CSV download * [x] Add Permalink action * [x] Integrate Permalink with Short URL service * [x] Tweaked Permalink action to work with SO custom URL * [x] Tweaked Permalink action to handle disabled state * [x] Updated unit tests with new features * [x] Added (basic) caching logic to avoid too many snapshot duplicate Short URLs * [x] New share function test suite created * [x] Extended `browser` service with a new method to have a blank tab in browser * [x] New helper functions in Lens to test Share feature <img width="375" alt="Screenshot 2023-01-11 at 12 58 30" src="https://user-images.githubusercontent.com/924948/211800819-60efe70a-9ebe-4bde-82e0-8fa264e8c4af.png"> <img width="427" alt="Screenshot 2023-01-11 at 12 58 36" src="https://user-images.githubusercontent.com/924948/211800825-ae7b86d0-0e42-4227-a425-cdcd94ec78cb.png"> <img width="426" alt="Screenshot 2023-01-11 at 12 58 40" src="https://user-images.githubusercontent.com/924948/211800827-73bfb773-b30e-495c-aa61-f5fd10f35d31.png"> <img width="428" alt="Screenshot 2023-01-11 at 12 58 46" src="https://user-images.githubusercontent.com/924948/211800830-89539c37-7495-48f0-9de6-b7d6f15b7397.png"> <img width="427" alt="Screenshot 2023-01-11 at 12 59 03" src="https://user-images.githubusercontent.com/924948/211800833-6f1843b9-ab22-49d9-adbd-8f5f588b52e7.png"> ### Notes #### Short URL requirement This feature strictly requires the ShortURL service to be enabled to work, otherwise the permalink feature is disabled for snapshot sharing. This requirement is not clearly stated in the Share menu (yet) like other app do as the Sharing flow had to be customised in Lens due to some other technical challenges. Would it be ok to workout a UI improvement as follow up? #### Context tech debt The way the locator works as injecting the shared state into the context produced a discrete amount of branching, due to inconsistency of the `context` type coming from different sources (Discover, Agg-based/TSVB, Lens itself...). Perhaps it's worth discussing having a refactoring of the context type here? #### Missing locator service Due to the way the sharing logic works in Lens the locator has not been exported from the `plugin` functions. I thought to add a custom function for it, but perhaps we could investigate a bit better whether this is needed and eventually its implementation in a follow up task. ## How is the snapshot URL generated? ```mermaid sequenceDiagram actor User User->>Share Snapshot URL: click Share Snapshot URL->> Lens ShortUrlService: Lens state Lens ShortUrlService->> Lens ShortUrlService: Check cache based on state Lens ShortUrlService->> ShortUrlService: Generate a Short URL ShortUrlService->> Lens ShortUrlService: new Short URL Lens ShortUrlService->> Application `getUrlForApp`: Build absolute URL Application `getUrlForApp`->> Lens ShortUrlService: final URL Lens ShortUrlService->>Share Snapshot URL: final URL Share Snapshot URL->>User: final URL copied in clipboard ``` ### Checklist Delete any items that are not applicable to this PR. - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [ ] [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 - [ ] Any UI touched in this PR is usable by keyboard only (learn more about [keyboard accessibility](https://webaim.org/techniques/keyboard/)) - [ ] 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)) - [ ] 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 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)) - [ ] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers) ### Risk Matrix Delete this section if it is not applicable to this PR. Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release. When forming the risk matrix, consider some of the following examples and how they may potentially impact the change: | Risk | Probability | Severity | Mitigation/Notes | |---------------------------|-------------|----------|-------------------------| | Multiple Spaces—unexpected behavior in non-default Kibana Space. | Low | High | Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces. | | Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks. | High | Low | Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure. | | Code should gracefully handle cases when feature X or plugin Y are disabled. | Medium | High | Unit tests will verify that any feature flag or plugin combination still results in our service operational. | | [See more potential risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) | ### 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: Kaarina Tungseth <[email protected]> Co-authored-by: Stratoula Kalafateli <[email protected]> Co-authored-by: Andrew Tate <[email protected]> Co-authored-by: kibanamachine <[email protected]>
Currently sharing a link to Lens visualization can only be done from a dashboard.
User was asking to be able to share a link directly from Lens
The text was updated successfully, but these errors were encountered: