-
Notifications
You must be signed in to change notification settings - Fork 8.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Dashboard Navigation] Make locator generic (#167928)
Closes #164748 ## Summary Previously, the link embeddable **always** used the Dashboard plugin's locator - this meant that, for portable dashboards (such as those in Security or in APM), navigation through the link embeddable would always send the user to the Dashboard plugin rather than staying in whatever context the portable dashboard was in. This PR fixes that by ensuring that each `DashboardRenderer` consumer can provide their **own** locator as a prop - this means that the Dashboard app can still use its own locator, while the Security/APM plugins (for example) can **also** define a locator so that navigation remains in the security/APM app. ### Security @elastic/security-solution-platform While I did my best to modify each portable dashboard implementation to include this new locator prop, without the full context on how each plugin wants to handle the link embeddable, I've had to make a few assumptions about the behaviour. For example, in security.... - The Security dashboards **not** respond to the query bar in the same way that they do in the Dashboard app - therefore, the link embeddable settings for "Use filters and query from origin dashboard" and "Use date range from origin dashboard" do not make sense in this context. For example, in Security, it is (from my understanding) **expected** that the query bar would always remain constant, regardless of these settings; therefore, these settings are more-or-less ignored. Unfortunately, this opens up a potential confusion for users, especially if the are editing/creating a link embeddable in the security context. - The Security app does not currently use real locators, and my attempts to remedy this were unsuccessful. Therefore, rather than requiring a **true** `Locator` object to be passed in as a prop to the `DashboardRenderer`, I had to instead accept any object that has both a `navigate` and `getRedirectUrl` method defined. It would be **much** cleaner for the Security plugin to define its own locator - that way, the `DashboardRenderer` could instead just accept a locator ID as a prop, and the link embeddable could use that ID fetch the appropriate locator as necessary; however, this is a pretty major refactor, since the Security app handles URLs/navigation in a much different way than any other Kibana app. **Before:** https://github.com/elastic/kibana/assets/8698078/67fdf34f-60e3-47fc-b205-8a6443a0452d **After:** https://github.com/elastic/kibana/assets/8698078/f92f1eb0-1467-4408-8792-f881e355188b ### APM @elastic/apm-ui While I did my best to modify each portable dashboard implementation to include this new locator prop, without the full context on how each plugin wants to handle the link embeddable, I've had to make a few assumptions about the behaviour. For example, in APM.... - Similar to the Security implementation, the APM dashboards **not** respond to the query bar in the same way that they do in the Dashboard app - therefore, the link embeddable settings for "Use filters and query from origin dashboard" and "Use date range from origin dashboard" do not make sense in this context. For example, in APM, it is (from my understanding) **expected** that the query bar would always remain constant, regardless of these settings; therefore, these settings are more-or-less ignored. That being said, because APM does not currently support dashboard editing, I believe this is less of a concern than it is for other implementations. - Because of the unique content management system that APM is using, where Dashboards must be linked in order for them to be viewed, the link embeddable would not work **unless** the user was navigating to a dashboard that was added to the APM Dashboard CM. I've had to change this so that **any** dashboard can be viewed in the APM context - that way, even if someone is trying to load a dashboard that is **not** linked, it will still load. This goes against how APM typically handles its dashboards, so I am open to suggestions if this behaviour is undesirable. It just felt odd to me that I would have to link every single referenced dashboard in the APM context if I wanted the link embeddable to work.... **Before:** https://github.com/elastic/kibana/assets/8698078/59397d42-2289-4721-9d4a-74c3e7a4d871 **After:** https://github.com/elastic/kibana/assets/8698078/87924826-e766-4b50-87c6-132ae936f2fc ### 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 ### 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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
- Loading branch information
1 parent
6ac15df
commit a7728e4
Showing
27 changed files
with
396 additions
and
305 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.