Hi Priscillareagan ,
I'd love to learn more about the hard requirement, as it feels like you're solving an issue caused by another issue here.
In any case I have a few notes:
- using widgetready event on the dashboard will fire for widget in widgets - so it looks like you're repeating your jQuery a few times (you're running it every time an individual widget becomes ready).
- I'm not sure on the timing aspect, but the widget may not be 'dom ready' by the time you use jQuery to change the style of elements - this will mean that it won't trigger.
- For jQuery to be able to change elements they need to already be rendered by the time you attempt to run it.
- The headless browser that prints PDF doesn't seem to always work the way we expect and is sometimes funny with dashboard scripts.
I have a dashboard script solution for you to try here:
prism.on('dashboardloaded', () => {
const elem = document.createElement('style')
elem.innerText = `
.z-s-t {
height: 0px !important;
width: 0px !important;
}
.w-t {
height: 0px !important;
width: 0px !important;
}
.ui-resizable-handle.ui-resizable-e {
height: 0px !important;
width: 0px !important;
}
.ui-resizable-handle.ui-resizable-s {
height: 0px !important;
width: 0px !important;
}
.widget-body.slf-widget-text-primary {
padding: 0px !important;
}
`
document.head.appendChild(elem)
})
The idea here is that by injecting a style to the header when the dashboard is first loaded - we apply the styles once (not per widget) and proactively (before the elements are created).
We use prism.on('dashboardloaded', ...) as this seems to play more nicely with the PDF than dashboard.on('initialized', ...) - but I have no actual idea why.
Please note that this will affect all widgets on the dashboard, so if your aggregate BloX table isn't the only 'widget' on the dashboard, this may cause the other widgets to appear weird. We can adjust CSS to select only the components you're interested in but would require changes.
Let me know how you go?
