Reporting Services report reference in dashboard designer, used on a Dashboard deployed to Performance Point - how to hide Report URL? RRS feed

  • Question

  • Hi -

    I have finally been successful using a SSRS report reference on a created Performance Point 2010 item using dashboard designer.

    We use SharePoint Intergrated as the mode.

    I add this reference to a web part zone on a dashboard and deploy it.  Everyone works as expected, but the only problem is that when it renders the report in the web part zone, it includes a blue heading that basically displays the entire report URL.  What's worse, you click the hyperlink, and you are brought to whatever part of the Sharepoint Site you click.

    Why on earth would this be displayed and not hidden by default for a dashboard, and is there ANY WAY to hide it?   

    I have tried all the options available on the Dashboard Design Reporting Services item (you can hide the toolbar, parameters, and docmap only)  tried editing the web part on the deployed page, and even looked at the SSRS report in Visual Studio.

    any help would be appreciated.

    And ADMINS : if this is in wrong section, please move?


    • Edited by MikeR_26 Friday, April 12, 2013 7:34 PM
    Friday, April 12, 2013 7:33 PM

All replies

  • Have you tried setting web part's property 'Chrome' to none? I believe it is the title of the web part which is displaying the url.

    Alternatively (as a desperate measure) you can use jQuery to hide it by using Developer tool (F12) to figure out id and hiding it on page load.


    Monday, April 22, 2013 9:07 PM
  • Mike, we had the same issue you reference.  It ended up being fixed with a service pack.  We experienced this issue running Sharepoint 2010 Aug 2011 Cumulative Update.  When we upgraded to Sharepoint 2010 Dec 2011 cumulative update it corrected the issue for us.  See this thread.



    • Proposed as answer by Dan English Tuesday, June 18, 2013 11:37 AM
    Friday, May 17, 2013 1:48 PM
  • Yep, I recall another client that I worked with that had this same issue, it was a bug that was part of a CU and was fixed later on as Ryan mentions here.  Make sure you keep a close eye on the SharePoint CU releases for fixes and that you properly test them before updating your production environments to make sure nothing breaks:)

    Dan English's BI Blog

    Tuesday, June 18, 2013 11:38 AM