cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Enable dashboard filtering for any field (not only project)

Enable dashboard filtering for any field (not only project)

It would be great if  it was possible to create a Dashboard, that could be used to automatically filter all content not for Project but e.g. a "Affected Product" IBPL field.
 
The overall functionality of the dashboard could stay the same, only the "implicit filter" would be set to a different field.
 
 
The API seems to be available as the CLI already has an appropiate Parameter

<quote>

...

--fieldFilter=field=[value,value,...]

specifies the field filter to be applied to the dashboard. Currently, only project field filters are supported.

....
</quote>
7 Comments

I agree.  See this community update.  You should add your comments there:  Parameterized queries.

Level 10

It would be good to be able to let Dashboards on a scheduled basis.

If it needs for eg. 5 minutes to get prepared completely, it would be good to let it run around 10 minutes before I need it.

Level 6

Hi Klaus, do you want to create a specific product improvement idea for this with a tag=dashboard and a link to this one? It is hard to support a comment else.

Level 11

Hi Klaus,

I think in you use case, maybe the Dashboard is not the right choice of weapon.

IMHO a dashboard should be a "customized view on live data".

The main focus is "quick & easy access".

As a result, a Dashboard should not contain Objects like Charts or Inline Reports that cannot "instantly" be rendered.

This means that all "trend" analysis (that are the main cause for delay) should not be part of a Dashboard.

IMHO the use cases for "deeper analysis" (requiring long running charts) should be covered by reports (maybe including JavaScript for rendering)

BTW

you can use "im rundashboard -g --fieldFilter=Project=<your project> ..."  in the CLI  to run/refresh your Dashboard in a scheduled OS Event.

Level 10

Hi Matthias,

thanks for your hints.

Of course you are true with suggesting to run a Dashboard creation in a scheduled OS Event, but this is no activity that is usefull for ALL Integrity user.

Especially team assistance in many cases aren't experienced to create such scripts.  (And to use them as dynamically like needed.)

On the other hand a Dashboard is "only" a summary of all other possible outputs you can create. There is neither an exclusion of for eg. Trend Charts, nor a recommendation not ot use them. See Basic description from Integrity Manual:

"What is a Dashboard?

A dashboard is a static, user-definable view comprised of any combination of the following components: embedded charts, embedded reports, images, labels, and links to queries, reports, and Web sites.

Dashboards can be used to view any collection of components as a single unit, but are especially useful to provide a high-level overview of the status of a project or set of projects. You can design one dashboard for all projects and select the appropriate project(s) from the dashboard project filter at run time."

Thus I can't agree with your post.

Level 10

My suggestion will be to include my post into this product idea.

Both care about improvements "How to define/run a Dashboard".

Level 7

Matthias Rump‌ I'm marking this for Future Consideration, for enabling Field Filter to be applied to the dashboard so as to be consistent with CLI behaviour.