[Portable Dashboards] Remove Saved Object Class#138774
[Portable Dashboards] Remove Saved Object Class#138774ThomThomson merged 47 commits intoelastic:mainfrom
Conversation
…eDashboard/removeSavedObjectClass
…eDashboard/removeSavedObjectClass
| /** | ||
| * A saved dashboard panel parsed directly from the Dashboard Attributes panels JSON | ||
| */ | ||
| export type SavedDashboardPanel = SerializableRecord & { |
There was a problem hiding this comment.
While on the surface having a type that guarantees that data is serialisable is a good thing, we should be very careful with the SerializableRecord or Serializable types. These are really anti-types in that they reduce type safety making code more prone to bugs.
As an example mySavedDashboardPanel.recordDoesNotExist.fieldDoesNotExist = 'some string' would happily pass the type checker. So it really has the same problems as using any.
I know this PR didn't introduce this type to the dashboard code, but if we could limit/reduce it's usage that would improve the quality of the code.
There was a problem hiding this comment.
I realised this problem is much bigger and we also have the SavedObjectAttributes type causing similar problems 🙈 https://github.com/elastic/kibana/pull/140099/files
There was a problem hiding this comment.
Hey @rudolf, this is a really good point! Let me look into removing any instances of SerializableRecord from Dashboard. I wonder if there are any Typescript extension types that we can use to enforce serializability without introducing that nasty key signature.
There was a problem hiding this comment.
I've removed a couple references to SerializableRecord here, but removing all of the SavedObjectAttributes imports from Dashboard is proving to be a big enough project to warrant its own follow-up PR. I have created this issue to track it
…thub.com/ThomThomson/kibana into portableDashboard/removeSavedObjectClass
…eDashboard/removeSavedObjectClass
…ersion lower than 7.3
…eDashboard/removeSavedObjectClass
…thub.com/ThomThomson/kibana into portableDashboard/removeSavedObjectClass
…eDashboard/removeSavedObjectClass
…eDashboard/removeSavedObjectClass
…thub.com/ThomThomson/kibana into portableDashboard/removeSavedObjectClass
…eDashboard/removeSavedObjectClass
…eDashboard/removeSavedObjectClass
…eDashboard/removeSavedObjectClass
|
Pinging @elastic/kibana-presentation (Team:Presentation) |
| screenshotMode: { isScreenshotMode }, | ||
| coreContext: { executionContext }, | ||
| data: { search }, | ||
| embeddable: { getStateTransfer }, | ||
| notifications: { toasts }, | ||
| screenshotMode: { isScreenshotMode }, | ||
| settings: { uiSettings }, | ||
| spaces: { getLegacyUrlConflict }, | ||
| data: { search }, |
There was a problem hiding this comment.
Very minor nit: I was trying to keep the services alphabetical when I did the abstraction, but I notice here you're ordering by the number of characters in the line - not sure if we want to be consistent about this? 🤷
There was a problem hiding this comment.
I always organize imports and de-structuring by number of characters to make the file look pretty ✨. The way I do it is definitely not something we should standardize in my opinion hahah. So that leaves two options here:
Option 1: We make alphabetical imports / de-structuring our team's standard, and we look into making a prettier / eslint rule to automatically do that for us.
Option 2: We leave it totally up to the engineer who is editing the file.
I'm totally okay with either option! @cqliu1, this is something the 3 of us should probably think about.
There was a problem hiding this comment.
I'm also good with either! Definitely something worth discussing so we can all get on the same page, since I know it's come up a few times at this point 👍
src/plugins/dashboard/public/application/embeddable/dashboard_container_factory.tsx
Show resolved
Hide resolved
src/plugins/dashboard/public/services/embeddable/embeddable.stub.ts
Outdated
Show resolved
Hide resolved
src/plugins/dashboard/public/application/top_nav/show_share_modal.test.tsx
Show resolved
Hide resolved
src/plugins/dashboard/public/application/lib/sync_dashboard_container_input.ts
Show resolved
Hide resolved
Heenawter
left a comment
There was a problem hiding this comment.
Code review only - looks like this realllly helps clean things up! Left a few nits and questions, but nothing code-specific stood out to me 👍
Will follow up with approval once I test this locally
src/plugins/dashboard/public/application/top_nav/show_share_modal.tsx
Outdated
Show resolved
Hide resolved
src/plugins/dashboard/public/application/top_nav/dashboard_top_nav.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Working on testing this PR as thoroughly as possible, and was able to get stuck in an unsaved changes state via the following steps:
- Create a new dashboard and save it with
Store time with dashboardoff - Click
Save as, untickSave as new, setStore time with dashboardtotrue - Change the dashboard time range - notice that this does not trigger unsaved changes, even though it should 🔥
- Go back to
Save as, untickSave as newbut keepStore time with dashboardastrue - Notice you get stuck in
unsaved changesand can't get out even if you discard changes 🔥
Screen.Recording.2022-09-23.at.2.54.43.PM.mov
If in step one you save the brand new dashboard with Store time with dashboard on in the first place, the unsaved changes badge seems to respond to time changes as expected - it's only when you go from Store time with dashboard off to on where things get buggy,
There was a problem hiding this comment.
Tested this and everything worked great minus the bug discussed in #138774 (review). Will approve once that is resolved so I can do another round of testing.
Saving and loading
For an empty dashboard and for dashboards with content:
- Quick save:
- Added and modified controls, renamed panels, moved them around, etc. etc. Everything worked as expected
- Save as:
- Saved dashboard with title, description, tags, and time store
- Made sure I could make changes to title, description, tags, and time store by unchecking
Save as new dashboardwhen saving - Get a warning when trying to
Save aswith duplicated title - can overwrite it
- Clone dashboard:
- Cloned the dashboard and ensured everything got copied as expected, including by reference and by value visualizations (if the dashboard wasn't empty), tags, description, and time store
- Get a warning when trying to clone with duplicated title - can overwrite it
Migrations
- Took a dashboard with content from
7.17.3and imported it - Took an empty dashboard from
7.17.3and imported it
Saved Object Resolve
Followed the steps outlined and everything worked as expected 👍
…eDashboard/removeSavedObjectClass
|
@Heenawter - I was able to fix the bug you described in #138774 (review). Nice catch! It was basically a matter of correctly applying all of the state from the save modal. I also cleaned up the state comparison of times a little bit to make it match with the rest of the state comparison. |
Heenawter
left a comment
There was a problem hiding this comment.
Reviewed code changes + re-tested the timeRestore bug and everything works great 🎉 Also tried the following and everything worked beautifully:
- Save a new dashboard with
timeRestore === true - Change the time and verify that
unsaved changesbadge shows up - Click
Save as, untick bothStore time with dashboardandSave as new dashboard, then confirm - The
unsaved changesbadge disappears as expected 👍
|
@elasticmachine merge upstream |
|
buildkite test this |
61452ce to
1d93a4d
Compare
|
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
async chunk count
ESLint disabled line counts
References to deprecated APIs
Total ESLint disabled count
Unreferenced deprecated APIs
History
To update your PR or re-run it, just comment with: |
Summary
Fixes #137200
Fixes #136767
This PR executes a number of large changes to the way that Dashboards are loaded from Saved Objects. This is required as preparation for the first phase of the Portable Dashboards project. Merging this PR will complete all remaining prep work items and allow us to move on to implementation.
What does this PR do?
useKibana, anddashboardAppState.DashboardAttributeswhich should be always be the latest / current state of the Dashboard Saved Object Attributes. Rather than keeping version information in this type, we should create new types to store the previous versions, maintainingDashboardAttributesas the source of truth for the latest typings.the unused
urllibrary function.Test Guide
Saving and loading
Make sure to manually save in as many ways as possible:
Everything should work correctly
Migrations
Export a dashboard from a version before 7.3 and import it into main. All of the saved object migrations should run correctly.Edit: It looks like versioning must go through 7.17.x before being upgraded to 8.x, for both upgrades and saved object imports. So we should be okay just ensuring that imports from 7.17.x work correctly.
Saved Object Resolve
To test the
conflict,exactMatch, andaliasMatchoutcomes of thesavedObjectsClient.resolvefunction, the results of which are used slightly differently in this PR you should:system_indices_superuser{your Kibana URL}/s/test1/app/dashboards#/view/b348e380-39d1-11ed-88ea-15ffd58ee0d7-test1and ensure that the dashboard loads properly.{your Kibana URL}/s/test2/app/dashboards#/view/b348e380-39d1-11ed-88ea-15ffd58ee0d7-test2and you should be redirected to another dashboard with the idb348e380-39d1-11ed-88ea-15ffd58ee0d7-newId{your Kibana URL}/s/test3/app/dashboards#/view/b348e380-39d1-11ed-88ea-15ffd58ee0d7-test3and the conflict warning should show.