Issues moving PA dashboards between instances

Uncle Rob
Kilo Patron

So I created a PA dashboard with two tabs & a dashboard breakdown.   Tab 1 has 9 report widgets and two Static HTML content blocks.

Tab 2 has 4 PA Widgets with a couple widget indicators each.   When I moved update set to test, I received these update set preview errors:

find_real_file.png

At first I thought I was on crack, and didn't have my update set "on" before configuring.   So I started all over.   Fresh update set.   New dashboard.   Same content.   Same update set errors when pushing to test.


I feel like I must be missing something obvious.

13 REPLIES 13

Adam Stout
ServiceNow Employee
ServiceNow Employee

Is this with Kingston previous?


Jakarta.   But PA has been a platform tool for more than a few versions now.   And it strikes me that Homepages had more or less the same problem.


Adam Stout
ServiceNow Employee
ServiceNow Employee

I believe Dashboards inherited the problem from homepages (although I'm not positive on that one).   In any case, it is now a one-button push in Kingston.   If it was automatically, we could certainly see a lot of noise in update sets.   The one button push makes it a lot more manageable than Jakarta and before.


stefaan1
ServiceNow Employee
ServiceNow Employee

(assuming you're using Responsive Dashboards and glide.cms.enable.responsive_grid_layout=true)



When the widget sizes don't match it is usually because A) a homepage is converted to a dashboard, or B) a tab and its content are converted from a Geneva version, or Helsinki version without Responsive Canvas, or C) the sys_grid_canvas_pane and/or sys_grid_canvas records are missing in the unload.



The sys_grid_canvas_pane records are holding widget position and size information, so when that's missing or incomplete you get size and/or position errors.



However, when the sys_grid_canvas record is missing it tricks the system into thinking you're opening that tab for the first time since Geneva/Helsinki, and it makes it convert the old layout system (when there is one) to the new responsive layout.



Because the legacy layout (based on UI Macros) used in both home pages and Geneva/Helsinki dashboards relies on HTML markup, which may not always correctly convey layout structure and widget sizes (DIV elements convey no structure at all, but TABLE elements do), we are forced to round off the results to the closest match in the new responsive layout during conversion. For instance, when a widget's width corresponds to 2.5 "responsive columns" it's going to be rounded off to 2 or 3 columns, and so will either be too wide or too narrow compared to the original size.


The height of widgets is yet another problem. If their height was not explicitly set as a fixed number of pixels, we have to give them a default height since the widgets HTML+CSS+JS can't be rendered server-side to find out what their size would be when displayed on a browser.



I know this won't take away the frustration, but I hope it at least explains what you're seeing.



(more about responsive layouts here)