Original Message:
Sent: Tue April 22, 2025 07:25 AM
From: Nick Williams
Subject: Dashboard - Hide Filters pane by default
@Michael Webb,
Hi... I work with @Marc Reed , and I'm helping him out with this idea. He's away on holiday this week, but I've been making progress.
Couldn't agree more with your comments about the native dashboard prompting. We've been saying this for years. Reporting has great prompting capabilities allowing you to create guided experiences for users, with context sensitive help, collapsible sections. We can author one report and have it be used by hundreds of different people, all getting different output specific to their requirements.
But if we want to do that with dashboards we have to tell users to scroll left and right in the global filters bar until they find the filters which then need to filter on their business area, their region, their function, etc. Then there's no way of saving those prompt answers other than saving the whole dashboard to their own areas. Then we've got hundreds of copies of the dashboard all over the place, so we can't make a change to a corporate dashboard in one place, unless we ask users to delete all their copies and set them up again from the new template.
Our users keep showing us a global filter page on some dashboards they have made in another BI product... Power something or other... and can't understand why we don't make a page on the dashboard like that. We've obviously explained that you cannot put global filters down onto the canvas, and that even if you did they would be so comically enormous that you would need a tab for each prompt, which wouldn't be much better than navigating the global filter bar.
As you say... the Cognos dashboard product seems to be aimed as a tool to answer specific questions for a handful of people. As soon as you add all the global filters you might need to have a dashboard which can be people all over the organisation, who all want it filtered in slightly different ways then it becomes unwieldy. But it could be so much more!
So, we're having a go at this. Thanks so much for sharing your code last year. That gave me just the start I needed. We're going with a similar approach, embedding a dashboard in an iframe in a report, but using the cross scripting instead of the URL. I've created:
- A dashboard extension which acts as a receiver, taking messages and converting them into dashboard global filters.
- A reporting custom control which acts mostly as a transmitter, transmitting messages containing the state of the prompts to the dashboard extension. This works for standard prompts, but I'm trying to enhance it to work with Custom Control prompts (which the page.getAllPromptControls() API can't scrape).
- I've got another reporting custom control which posts the parameters back to the server without using next() or finish() (which reload the report, which we don't want). This allows us to save our prompt answers as a report view, so the users can just open that next time without having to answer the prompts again. I'm hopeful when we move to 12 there might be better ways to do this... its a bit more hacky than I would like.
- Like you, we want to have more interactive search prompts. From the cascade.js sample I can see how you can build a dataset containing just the information needed for prompting, and then do all the searching client side in javascript rather than posting back to the server all the time. I'm at the foothills of this challenge.
So, I've got quite a long way with this integration. As you correctly point out, it's a pile of effort to make it suitably generic that we could deploy it to lots of different types of dashboards, and suitably robust to be productionised... and if it doesn't meet those two criteria then there's no point.
It sounds like we're very much aligned with the functionality we want to try to wring out of this product. I don't see how you can drive 'corporate', 'standard', 'enterprise' dashboards across very large organisations without better functionality in this space. But given that this has never been a priority for the CA dev team it does seem like we're out on a limb here. Perhaps dashboards shared across the enterprise is a more niche requirement than I thought... maybe it's just you and us who want this. Certainly every time I see dashboards demoed I never really see this use case.
Anyway, is this something you would like to collaborate with us on? Or, has the move to Tab... whatever it is, eclipsed all this for you? I'm not clear whether you still have some Cognos on your estate, and you've just implemented this particular requirement elsewhere. We'll do the heavy lifting, but I couldn't have got this far without your input and you've hinted you've got more goodies in your toolbox!
Thanks
Nick
------------------------------
Nick Williams
Original Message:
Sent: Wed April 16, 2025 07:31 PM
From: Michael Webb
Subject: Dashboard - Hide Filters pane by default
@Marc Reed,
I haven't used the cross site scripting api because honestly the documentation is terrible and the amount of work required was beyond the scope of my role where I work. I have experimented on it in the past and it could work but I think to build all the necessary features to make it happen is a mountain of effort.
I think the simplest way to do this with the cross site example is creating a bunch of different custom controls prompt components like redesigned Search and Select, Single and Multiple Select, Tree, Radio, Date picker, etc... and use datasets to populate the prompt values. Specify in each custom control the dashboard full destination column name and related dataset column name.
You might need to create a state manager custom control to handle all the cross context state mangement so they don't conflict with each other when applying a prompt selection and allow features like cascading prompting.
In the past, my hacked solution was to make a report that had the same dataset as the dashboard and then use cognos report prompts to create an invisible list which I then used a single custom control to build a dashboard url with the url filters as url params.(This only works up until a point. URL Length limits become an issue with lots of selected items) Then I embed the dashboard in an iframe and if I changed the report prompts it would just reload a new instance of the dashboard with the new url params. This worked well for a while but it was too customized for that report to implement in production for other dashboards. We switched to another BI Tool named Tab.....something or other and we stopped development on the cross site stuff.
It's not an impossible task but for a single individual doing it for work just doesn't make sense unless you are developing it as a product. I have created some administrative tooling that I have wanted to maybe offer publicly but creating fully featured custom prompt components is a complex task. I have currently spent a few weeks of work trying to create a custom Search and Select Combo box for reports that is more interactive but I paused the project due to trying to make it accessible. I also tried using IBM's carbon design system to develop custom components but the build process was also a pain point for me.
I think the best solution is for dashboards to get redesigned native filter components, collapsible sidebars for filters that can be rearranged, and a more robust drill through api from reports to dashboards. I don't know why the IBM Cognos developer team haven't done more work on this because the pipes are laid down for a really unique integration between reporting and dashboarding. It is a shame that it just got forgotten about.
Also a small side note, the default filter widgets when added to the canvas are comically enormous.
Cognos dashboards are best when they don't involve more than a small handful of simple filters per tab/page and the designer puts a lot of effort into curating the dashboard to answer specific questions. Anything more and it feels overstuffed.
For context on the documentation:
Not super well advertised and hasn't been updated since 2021 but this is the api docs/library to control a cognos dashboard: https://ibm.github.io/ca-dashboard-js-api/11.2.0/AppFactory.html
------------------------------
Michael Webb
Original Message:
Sent: Tue April 15, 2025 08:28 AM
From: Marc Reed
Subject: Dashboard - Hide Filters pane by default
@Michael Webb
Hi Michael.
Did you get anywhere with the future solution you mention above?
The idea of using a report to control the dashboard global filter bar via cross window scripting/api? Using a report to control the dashboard global filter bar is a prize that would overcome the existing dashboard global filter bar UI.
I found this in the accelerator catalog:
Cross window scripting dashboard javascript api
Or if any other Cognos developer has done something similar could they please share.
Thanks.
------------------------------
Marc Reed
Reporting Lead
Original Message:
Sent: Tue May 21, 2024 12:34 PM
From: Michael Webb
Subject: Dashboard - Hide Filters pane by default
Hi Philipp,
My method is a little convoluted and specific to my use case. Our data warehouse has a fuzzy lookup of multiple columns for organization parameters so my mappings required validating multiple columns against each other so it's hard to give you a lot of details without getting confusing so I will tell you my steps and then generalize it for you. Also it doesn't work if you select too many parameters but this is how I did it.
I created a report page with a prompt and a list that gets filtered by the prompt and I added an several HTML items on the page. the HTML items held a couple spans with information from the query the prompt generates, and an empty iframe which we render the dashboard inside.
I then created a custom control called DashURL which uses the dashprompt.js in the file I shared. This custom control scrapes the prompt api to get all prompt key value pairs and then maps them to a new object structure. My use case required validating the prompt output with the values returned in the list because my data sources for the prompt and the dashboard were different so all the prefixes and column names needed to be mapped out.
This object structure is the same one that dashboards use to drill through to another dashboard and then it gets appended to the url. The problem is the url length can max out pretty easily so its best used if you don't need to select many values in a single prompt. I want to note, that this object structure is also verbose.
The way the object structure works is you need to define a scope (page, widget) through getting the widgetId or the highest level widgetid in the report specification for the dashboard. You need to be able to have the name of the column you want to filter, operator which is the ( in, and, or) for the filter, and the filter values which is an object of display and value. Then you make an array of all the filters you want to apply and place them in an object formed like the one below:
{
options: {
overrideExistingFiltersOnly: true/false,
matchMetadataAcrossSources: true/false,
},
filters: [
{
scope: widgetId,
columnId: columnName,
operator: "in",
values: {
u: "displayValue -> [valueValue]",
d: "valueValue"
}
}
],
}
I then encodedURI this object and added it to the dashboard url like this:
.../bi/?perspective=dashboard&pathRef=...&closeWindowOnLastView=true&ui_appbar=false&ui_navbar=false&shareMode=embedded&action=view&mode=dashboard&filters=${encodedFilterObject}
Then I take this new url and add it as the src for the iframe in the html item we placed on the page.
Now at the time this method had some drawbacks. I believe it is changed now in 12.0.3 but in previous versions we had an issue in reports where search and select prompts would rerender the page when you ran the search query. This would cause the dashboard to also rerender and was cause for slow performance and extra fetch requests for the dashboard on each render. Also if you selected too many filter selections it would max our the URL length and the dashboard wouldn't grab all the filters or any of them.
My future solution is to create a similar method using the cross window context api for dashboards and have prompts pass the values to the dashboard that way. I think that is the best possible way to use report prompts to manage the dashboard filters. Since the newer prompts now can run without rerendering the page it should make it much easier to implement.
Hope that helps!
p.s. I also want to use the custom control datastore instead of lists for future versions to make the logic less complicated.
------------------------------
Michael Webb
Original Message:
Sent: Tue May 21, 2024 11:19 AM
From: Philipp Hornung
Subject: Dashboard - Hide Filters pane by default
Hi Michael,
How did you manage this?
"...default filters come from a report which embedded my dashboard and passed the filters to the dashboard."
I'm not aware of a way to pass filters from a report to a dashboard but I would like to know.
Best regards,
Philipp
------------------------------
Philipp Hornung
Business Intelligence Manager
Techniker Krankenkasse
Hamburg Germany
#IBMChampion
Original Message:
Sent: Mon May 20, 2024 04:27 PM
From: Michael Webb
Subject: Dashboard - Hide Filters pane by default
Not out of the box. If you have a filter applied as a default setting it will always show the filter bar on open. I created a Cognos extension that checks for the loading of widgets on the page and closes the filter bar once the page is loaded. Use the widgetID and add it to the Widget ID's box. You can decrease the opacity or push the z index to be behind all visible widgets to hide it. I have tested it only with 11.2.4 and 12. Not certain if it will work with 11.7.
I needed this function so that I could make the default filters come from a report which embedded my dashboard and passed the filters to the dashboard. It was a pretty crazy hack to use report filters for a dashboard and I needed to hide the dashboard filters to make it easier for users to know where to change filters. I hope this is helpful for you!
------------------------------
Michael Webb
Original Message:
Sent: Mon May 13, 2024 12:11 PM
From: Eric Mueller
Subject: Dashboard - Hide Filters pane by default
Is there a way of hiding the filter pane in dashboards so it shows a collapsed view when the user opens the dashboard up???
------------------------------
Eric Mueller
------------------------------