Reporting Services web parts on SharePoint page

Problem
Adding Report Builder web parts to SharePoint 2010 made the page colorful and intelligent, but the UI lacked a bit. The parts that took up little horizontal space and lots of vertical space looked kind of goofy;

  • the data abruptly cut off vertically after 11 inches
  • they required a fixed vertical setting at about 2000px
  • they would not flow horizontally with the page’s liquid layout
  • they sometimes created two layers of scroll bars making moving around on the page very awkward

Solution
Data typically cuts off vertically after a certain length because of paging; the page breaks based on the Interactive Size setting of the Report pane set in Report Builder. The fix is to set the InteractiveSize settings to 0. Might as well do it on both horizontal and vertical properties.

Avoid the fixed vertical and horizontal web part settings in SharePoint by using a wee bit of jQuery, unless you are free to do it with a server-side package. Start by removing any Height and Width settings in the web part.

Then add jQuery code in an HTM file strategically placed in a Documents Library like “Scripts” at some root site and call the file from a Content Editor web part on the report page. The following code seems to work – it works on ALL Report Builder web parts on the page and avoids conflicts with other parts.

<style type="text/css">
	.dynamic-height {height:auto !important;}
</style>
<script src="http://domainname/somerootsite/scripts/jquery-1.6.2.min.js"></script>
<script type="text/javascript">
	// use setTimeout method to delay
	$(window).load(function() {
		setTimeout("FixReport()",2000);
	});
</script>
<script type="text/javascript">
	function FixReport() { 
		// fix report height
		$('div[RSViewer="RSViewer"] div').addClass('dynamic-height');
		// remove report horizontal scrollbar
		$('div[id$="ReportViewer"]').css("overflow-x", "hidden");
	}
</script>

Even if the Report Builder web parts only have 2″ to 5″ of width, you can extend the part up to 12″ wide. It will allow a single column page fill out nicely to the right when the browser expands to fit larger screens – same for parts in side-by-side zones.

References:
See Article 1, Article 2, and Article 3

Advertisements

Automatically closing a SharePoint 2010 Edit form opened from a Reporting Services web part

SharePoint 2010 Edit and Display forms can be modified with InfoPath. This opportunity comes with a few new bugs, but the UI and functionality can be compelling.

It takes a snippet of Javascript, but a Reporting Services web part can open one of these new list or library Edit forms with a GoToURL action. On submit or close, however, the form will either close to the list it came from or it will close to a “This form has been closed” window. It matters not whether the form is opened in the same window (target = _self) or in a new window (target = _blank). Nor does it matter if the form is set to close on submit. Neither option closes the form back to the page that launched it, and both interrupt the user flow with additional clicks to close the form window.

If adding code to the form page is a non-starter, one workaround is to close the form to another page where script can be added. This is done using the &Source part of the URL string that opens the window.

Step 1 – Create a simple SharePoint ASPX page. This can be done using SharePoint Designer 2007 (adds the basic ASPX lingo automatically), Visual Studio, NotePad++, or etc. That should result in something like the following tags:

<%@ Page Language="C#" %>
<html dir="ltr">
	<head runat="server">
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
			<title>Untitled 1</title>
		<meta name="Microsoft Theme" content="Providence 1011, default">
	</head>
	<body>
		<form id="form1" runat="server"></form>
	</body>
</html>

Step 2 – Add Javascript to the section that has the page close itself on open. Calling open() first, bypass a potential window close confirmation dialog box.

<script language="javascript" type="text/javascript">
    window.open("", "_self");
    window.close();
</script>

Step 3 – Save the page as “Close.aspx” and upload it to a Document Library on the SharePoint site that is easy to access.

Step 4– Set the &Source parameter in the Report Builder web part’s URL expression to the url of the Close.aspx page. This is the URL that InfoPath will return the user to after the browser form is closed. The example below links to an Edit form in an External List that opens a specific item based on its BDCIdentity ID:

="javascript:void(window.open('http://sitecollection/site/Lists/ListName/Item/editifs.aspx?ID=" + Fields!BDCIdentityKey.Value + "&Source=http://sitecollection/site/Pages/Close.aspx','_blank'))"

The resulting link should open the Edit form in a new window, and when the form is saved or closed, it goes to the close.aspx page that closes instantly, leaving the user back at the window of origin.

References:

  • http://johnliu.net/blog/2011/6/17/infopath-2010-close-the-browser-window.html
  • Access Denied for Visitors on a SharePoint Page with Reporting Services Webpart

    If you are working in SharePoint 2010 and discover that users in the Visitors group or All Authenticated Users are unable to open pages that contain a Report Services web part with an Access Denied error…

    error message… you might think the issue is related to permissions. Then again, it may just be something quirky about the platform that prevents groups with Read permission from seeing reports that were published as a minor version.

    The solution: make sure the reports are published as a Major version. You can use “draft check” button on page tab of the ribbon bar to Publish a Major Version, or change the Report Library versioning settings to publish only major versions and re-save the reports.

    How to use a URL to launch Report Builder 3.0 and edit a report

    Make it easy for SharePoint site owners to edit their custom SSRS reports, by giving them a hyperlink that opens the Report Builder 3.0 application to a specific report.

    This MSDN article and this Technet article show how the Report Builder application can be opened from a browser.

    A native mode installation URL would be:

    http://mycompany.org:8000/ReportServer/reportbuilder/reportbuilder_3_0_0_0.application 

    … where “8000” would be the port you used when setting up the ReportServer service, while SSRS configured in SharePoint integration mode would take the form of:

    http://mycompany.org/mysite/_vti_bin/ReportBuilder/ReportBuilder_3_0_0_0.application

    You might find it easier to open the application to a specific report by appending a “?” to the end of the latter URL followed by the report path. Replace spaces in the path after the question mark with plus signs, and skip the “rdl” file extension on the end. For example, to access a “Department Report.rdl” file in a library on a SharePoint site called “Reports Library,” the following URL should work (all in one line):

    http://mycompany.org/mysite/_vti_bin/reportbuilder/ReportBuilder_3_0_0_0.application?http://mycompany.org/mysite/Reports+Library/Department+Report
    References: