SharePoint (and Project Server) Shenanigans

You may encounter an exception when running certain SQL Server Reporting Services (SSRS) reports.

The exception message will generally say something along the lines of Operation is not valid due to the current state of the object.

You may encounter this either in reports with a large number of parameters, or in reports where the parameter counts are low but the parameters themselves are multiple choice and have a large number of items selected.

The cause of this is a security fix released by Microsoft under Security Bulletin MS11-100. The fix, among other things, limits the number of keys that ASP.NET applications can parse as part of a request; large numbers of keys could potentially allow a denial of service to occur.

Unfortunately the effect of this is that our large parameter set is blocked, causing the exception and presenting a nasty error to our end users.

Luckily there is a solution to this.

The trick is to add a section to your web.config inside the <appSettings /> section.

<appSettings>
	...
	<add key="aspnet:MaxHttpCollectionKeys" value="5000" />
	...
</appSettings>

The actual value used should reflect the number of keys you believe will be used, but 5000 is a reasonable starting point.

If you are using SSRS in native mode, the web.config file is located within the reporting services installation path, usually C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer.

If you are using SSRS in SharePoint integration mode, the modification needs to be made to the web.config of the application pool where you are running your reports. For this I would recommend that you create a solution that utilises the SPWebConfigModification class as part of a feature receiver, rather than making the changes directly. This will ensure that the change is made across your SharePoint farm simultaneously without the human error that could come from doing the change manually on multiple servers.

Note: In both cases, these modifications either require a restart of the reporting server or in the case of SharePoint a recycle of the Application Pool. This will result in short outages so you will want to schedule this as part of maintenance accordingly.

For more information I would recommend reading the relevant KB article.

via Chris on SharePoint http://spchris.com/2013/05/sql-server-reporting-services-reports-errors-when-large-numbers-of-parameters-are-selected-2/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)

When working with SharePoint’s UI, it is often difficult to work out where in the URL structure you are.

You may for instance be working at the root of a site collection, but that itself may be several layers deep.

Take the following example.

You have a site collection for your company, but each team maintains its own site collection under the managed path (with wildcard inclusion) /teams.

Some of the team sites use a template that includes a master page that references an image gallery script. This gallery script has to load images out of a document library local to each team site.

The problem of course is determining the URL to the code and images, when they could be located at /teams/team-a/gallery images or /teams/team-b/gallery images

Of course in a server-side solution this is simple, SharePoint provides the handy shortcut of ~sitecollection. This works both directly in master pages:

<SharePoint:ScriptLink runat="server" Name="~sitecollection/Style Library/js/galleryscript.js" Language="javascript"/>

Or using a custom action within a SharePoint solution, sandboxed or otherwise:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<CustomAction
		ScriptSrc="~sitecollection/Style Library/js/galleryscript.js"
		Location="ScriptLink"
	/>
</Elements>

But how do we achieve the same within the front end itself?

Introducing _spPageContextInfo

The _spPageContextInfo object is a really wonderful little thing. It is added by the SPWebPartManager control, which is included in all of the out of the box master pages (including default.master and system.master) and I really strongly recommend is added to any custom master pages you create.

Because of it’s essentially omnipresent nature it makes using _spPageContextInfo a really simple matter of, well, using it.

It is a small object, containing only a few properties of the page, the site and the site collection it is part of. Here is a JSON representation of what it contains.

{
	alertsEnabled: true,
	allowSilverlightPrompt: "True",
	currentLanguage: 1033,
	pageItemId: 1,
	pageListId: "{6300d68a-4512-49f0-85b9-d3671855e31c}",
	siteServerRelativeUrl: "/teams/team-a",
	userId: 1,
	webLanguage: 1033,
	webServerRelativeUrl: "/teams/team-a/subsite",
	webUIVersion: 4
}

Here’s a brief explanation of the properties in it.

alertsEnabled

This one is simple, is SharePoint’s alerts email notification service enabled for the current web application. This maps to the SPWebApplication.AlertsEnabled property.

allowSilverlightPrompt

Will the user be prompted to download Silverlight if they do not already have it when they attempt to use Silverlight based UI elements. This maps to the SPWebApplication.AllowSilverlightPrompt property.

currentLanguage

This is the current locale being used by the user, if they have not changed it to a custom one, then this maps to the SPWeb.Language property.

pageItemId

This is the ID of the current page’s item within the document library containing it.

pageListId

This is the GUID of the document library containing the current page.

siteServerRelativeUrl

This is the path of the site collection, relative to the web application.

userId

This is the user’s ID for the current site collection.

webLanguage

This is the default language for the current web. This maps to the SPWeb.Language property.

webServerRelativeUrl

This is the path of the web, relative to the web application.

webUIVersion

This is the UI version of the current web, determining if the master page and components in use and available is compatible with SharePoint 2007 (3), SharePoint 2010 (4) or SharePoint 2013 (5)

Note: The actual properties available varies depending upon where you happen to be. For instance the pageItemId and pageListId properties do not exist within system pages, as they do not have IDs and do not live within document libraries.

That’s pretty cool, but how do we use it?

Well, as they are properties we can pretty much use them however we wish. Let’s take a look at a simple way of referencing files in our gallery images document library, for example referencing a logo to use on the homepage.

(function() {

	// The path to the image.
	var imagePath = '/gallery%20images/logo.jpg';

	// The relative URL is usually without the trailing /
	// however if we are on the root site collection then it
	// is simply / on its own and must be handled.
	if (_spPageContextInfo.siteServerRelativeUrl == '/') {
		imagePath = imagePath.substring(1);
	}

	// Build our full image path.
	imagePath = _spPageContextInfo.siteServerRelativeUrl + imagePath;

	// Finally set our image's source to the images path
	$('img#logoImage').attr('src', imagePath);

})();

Of course this is a rather contrived example, and you should probably be using the client side object model (CSOM) to pull items from a document library. However I hope it demonstrates how the object can be used.

A common use I use this for is is actually with the CSOM.

var ctx = new SP.ClientContext(_spPageContextInfo.webServerRelativeUrl);

I do it this way because I have had issues with concurrency when using the get_Current() method in SP.ClientContext when there is other code in use on pages that I do not have control over.

via Chris on SharePoint http://spchris.com/2013/05/managing-path-context-in-sharepoint/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)

One of the many pieces of functionality added in SharePoint 2010 was the dialog window, this is a nice little control implemented in JavaScript that allows us to display a “lightbox” style dialog, containing either another page within our site or direct HTML.

This post will explain how to pass information back and forth between the page creating the dialog and the page displayed within that dialog.

Firstly lets take a look at the JavaScript on our calling page. This could be added through any of the normal methods of inserting JavaScript into a SharePoint page.

(function() {

	// Use jQuery to wait for the DOM to be ready
	$(document).ready(function(){

		// Use SharePoint's SOD (script on demand) to wait for SharePoint to be ready
		ExecuteOrDelayUntilScriptLoaded(function() {

			//Create an options object (valid options properties reference - http://msdn.microsoft.com/en-us/library/ff410058(v=office.14).aspx):
			var options = SP.UI.$create_DialogOptions();

			options.title = "My dialog";
			options.autoSize = true;
			options.url = "/pages/myPage.aspx";

			//arguments to pass in to dialog (standard anonymous object)

			options.args = {
				someKey: "Some Value",
				someOtherKey: "Some Other Value"
			}

			//callback to handle the result from the dialog, you process the result of your
			//dialog from the origin page.

			options.dialogReturnValueCallback = function(result, arguments) {
				if (result == SP.UI.DialogResult.OK) {

					// Our arguments parameter contains the arguments originally passed to the dialog, so we could
					// reference arguments.someOtherKey here for instance and it would contain the value "Some Other Value"

					SP.UI.Notify.addNotification("OK Button clicked");

				} else if (result == SP.UI.DialogResult.Cancel) {

					SP.UI.Notify.addNotification("Cancel button clicked");

				}
			}

			// Create the dialog with options.
			SP.UI.ModalDialog.showModalDialog(options);

		}, "SP.UI.Dialog.js");

	});

})();

As you can see, there are 3 major parts to this, the options object, the args object and the callback.

The options object is created using the SP.UI.$create_DialogOptions() factory, although I have seen people using an empty object without apparent issue.

Into this you set various options affecting the way the dialog is presented, such as title, size and the url to the page to be displayed. A list of available options is posted on MSDN.

The args object is actually a property of the options object, and can be any sort of JavaScript object, be it an anonymous object like in our example above, or a closure, or a data model or anything else you may wish to send. This object will be available within the page shown in your dialog.

The last part is the callback, this is also a property set against the options object, and is a callback method executed when the DialogClose() method is called from within the parent page.

It takes two parameters, the result which should be one of the members of the SP.UI.DialogResult enumeration and the arguments, which can be any kind of variable or object returned from the dialog page.

Additionally in here you can call SP.UI.ModalDialog.RefreshPage() – this method takes a single parameter and is designed to be called using the result value from your callback. This method ensures that the page refreshes if the result is equal to SP.UI.DialogResult.OK

With these three sections we can define how our dialog looks, what data it takes in, and what happens once it is closed and how to process the data that comes back from it.

Lastly the dialog itself is opened using the call to SP.UI.ModalDialog.showModalDialog()

Now lets take a look at the other side of the coin, here’s the JavaScript code to run within the dialog page.

(function() {

	// As on the parent page, wait for the DOM and SharePoint to be ready before doing anything.
	$(document).ready(function() {
		ExecuteOrDelayUntilScriptLoaded(function() {

			// retrieve a reference to the page that called us.

			var _parent = SP.UI.ModalDialog.get_childDialog();

			// If this is false, then chances are you have browsed to the page directly rather than
			// loaded it in a modal window.
			if (_parent) {

				// Pull through the arguments sent to the dialog.
				var args = _parent.get_args();

				// set a red alert status line with our argument.
				var status = SP.UI.Status.addStatus("someKey:", args.someKey);
				SP.UI.Status.setStatusPriColor(status, "red");
				
				// Add handlers for our ok and cancel buttons
				$("#okButton").click(function() {
					// This closes the modal dialog and runs the callback method defined on the parent page.
					SP.UI.ModalDialog.commonModalDialogClose(SP.UI.DialogResult.OK, args);
				});

				$("#cancelButton").click(function() {
					SP.UI.ModalDialog.commonModalDialogClose(SP.UI.DialogResult.Cancel, "cancel clicked");
				});

			}

		}, "SP.UI.Dialog.js");
	});
})();

This again is fairly simple, we first of all get a reference to the calling page in the variable _parent. Then if that has been successful we pull in the args object from our options variable above.

Once at this point the world is your oyster, you can use the arguments from the parent page however you wish to display the dialog or interact with your users.

To close the dialog you can use SP.UI.ModalDialog.commonModalDialogClose(). This again takes two parameters, the first should be a member of the SP.UI.DialogResult enumeration, the second can be any object to send back, these map to the variables sent to our callback function above.

Additionally in here I have made use of some of the other neat parts of the SP.UI namespace such as the status bar and notification system. These are beyond the scope of this post but they’re pretty awesome and you should go read about them.

So there we go, by now you should be able to add true SharePoint style dialogs to your pages with minimal effort.

via Chris on SharePoint http://spchris.com/2013/04/dr-popup-or-how-i-learned-to-stop-worrying-and-love-the-modal-dialog/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)