-
Notifications
You must be signed in to change notification settings - Fork 8.6k
NP Migration: Dashboard URLs #49060
Copy link
Copy link
Closed
Labels
Feature:DashboardDashboard related featuresDashboard related featuresFeature:NP MigrationTeam:VisualizationsTeam label for Lens, elastic-charts, Graph, legacy editors (TSVB, Visualize, Timelion) t//Team label for Lens, elastic-charts, Graph, legacy editors (TSVB, Visualize, Timelion) t//discuss
Metadata
Metadata
Assignees
Labels
Feature:DashboardDashboard related featuresDashboard related featuresFeature:NP MigrationTeam:VisualizationsTeam label for Lens, elastic-charts, Graph, legacy editors (TSVB, Visualize, Timelion) t//Team label for Lens, elastic-charts, Graph, legacy editors (TSVB, Visualize, Timelion) t//discuss
Type
Fields
Give feedbackNo fields configured for issues without a type.
When moving to NP we plan to split up the current "kibana" app into multiple apps for the various parts (discover, dashboard, visualize, management and so on).
To do this we have to migrate the URLs. Currently dashboard is using the following routes:
/app/kibana#/dashboardsas listing page/app/kibana#/dashboardas new dashboard page/app/kibana#/dashboard/:idas saved dashboard pageURLs are mapped to their respective apps by the URL prefix which means it should not use both
dashboardsanddashboardas a first path segment.We can keep both prefixes for now and just re-initialize the app when switching between listing and actual dashboard, but on the new platform we should clean this app as we have to forward URLs anyway. Suggestion:
app/dashboardsas listing pageapp/dashboards/createas new dashboard pageapp/dashboards/view/:idas saved dashboard pageWith this scheme we can safely forward existing URLs to their new counterparts. It is also close to the URLs of visualize (
/visualizefor listing,/visualize/createfor new visualizations,visualize/edit/:idfor existing visualizations). Having/view/:idalso containing the edit mode is not super nice (having a separate/edit/:idpath would be better) but as this is currently part of the app state it's difficult to migrate, so I don't think the complexity is justified.