SP2010: Aggregating tasks with search
Ok. This is quite a common scenario. You’ve got your SharePoint site setup which consist of multiple webs, maybe (probably) even multiple site collections. Your user is member of a handfull of sites and get’s tasks assigned. You need your user to stay informed about the tasks he needs to perform. You’ve got a couple of options.
First, I would enable the “mail when task is assigned” option on your task list. This will notify the user a new task has been assigned. Also, with some workflows like approval / feedback request, you get automatic notifications when a task is due. Nice. But your users will start overlooking these mails, or just plain ignoring them. They start requesting an overview of all tasks assigned to them.
Now you’ve got multiple options. Waldek Mastykarz has got a nice post about using the Content Query Webpart to show info from subwebs. Works great, but the content query webpart is limited to the current site collection. Also, it’s proven to be hard for novice users getting the XSL right.
So what about a cross site collection option which is easy to configure? There are a few options, third party solutions probably being the best. For instance, there’s Lighting Tools with their conductor webpart, or Bamboo Solutions with a list rollup webpart (links are not sponsored by the way).
But wait! There’s an out of the box options you might want to consider: search! Using the default webparts (you will need SharePoint Server or Search Server Express for this), you can quite easily list all tasks assigned to the current user. It does require a tiny little bit of coding. Let’s get started!
1. First, let’s set a scope for this blog. We want to list all unfinished tasks which are assigned to the current user. We don’t care about the delay search causes, since results won’t be instant (depends on your crawl settings).
2. Start by setting up search. I’ll assume you’ve got search up and running. Open the search administration page and view the Metadata properties. Click on ContentType and make sure the “Allow this property to be used in scopes” checkbox is set.
3. Find the “Status” property. Make sure that all status metadata fields you want to use are linked. For the default status fields of tasks, this appears to be ok by default.
4. Now it’s time to create a custom scope. This will make it easy to only search for tasks and not other things which might have the AssignedTo field. Though, if you want to search just everything which is assigned, you could skip this step (and ok, you didn’t need step 1 either… sorry :)). Create a new scope via “Scopes” in your Search Administration. If you do create a scope, let’s assume you named it “Tasks” (feel free to choose another name though, doesn’t matter). Add a rule to it, which should be of type Property Query, select ContentType as the property and enter Task as value. Now your scope will include only those items which are of type Task. Of course you can enter your own custom content types as well.
5. Once you’ve got all that setup, add some test tasks anywhere on your site. Assign some to yourself, some to other users. Also try some different statuses for a good test scenario.
6. Run a crawl to make sure your new tasks are ready to be found by search.
7. Now you should be able to search for your tasks. That’s quite easy if you know the syntax. Enter this in your search field: AssignedTo:”Jasper Siegmund” (substitute your own name). If you set it up ok, this should list some tasks. Select the scope or add Scope:”Tasks” to your query to make sure only tasks are shown. Now if you want to limit to tasks which are not marked Finished, just add NOT(Status:”Finished”). The picture is clear I think; you’ll get something like:
AssignedTo:”Jasper Siegmund” AND Scope:”Tasks” AND NOT(Status:”Finished”)
8. Cool. But this still requires entering a search query, and you’d rather give your users a webpart which does the same without requiring any input. That’s not too hard either, although this step does require a little bit of coding.
8-1. Open up Visual Studio, create a SharePoint project and add a new webpart. I’ll assume you know how to do that.
8-2. Make the webpart inherit from CoreResultsWebPart, which is found in Microsoft.Office.Server.Search (found in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI).
8-3. Override the GetXPathNavigator method like this:
protected override System.Xml.XPath.XPathNavigator GetXPathNavigator(string viewPath)
{
QueryManager qm = SharedQueryManager.GetInstance(this.Page).QueryManager;
try
{
string name = SPContext.Current.Web.CurrentUser.Name;
qm.UserQuery = String.Format("AssignedTo:\"{0}\" ", name);
qm.UserQuery += "AND Scope:\"Tasks\"";
qm.UserQuery += "AND NOT(Status:\"Finished\") ";
}
catch { }
return base.GetXPathNavigator(viewPath);
}
Again it’s pretty straightforward. Modify the UserQuery property of the QueryManager object to match the query you want to fire. You might wonder why the GetXPathNavigator method it’s used. To be honest, I don’t know for sure, it’s probably the one which comes after the normal webpart properties are loaded internally. But place the same code in the OnLoad event and it won’t work!
Now you can deploy your webpart to a site and voila: the tasks are shown in a search results view! You can modify that view to your own needs, but that’s a different post I might add later on.
One final note: this will only work for users with a proper Name. The SHAREPOINT\system account for instance, doesn’t have one, so that won’t work. But you shouldn’t be assigning tasks to that account to begin with, so that’s not a big problem.
Thanks to Sjoukje Zaal who wrote a post on SPCNL explaining about the scope aggregation part: http://www.spcnl.nl/2012/07/data-uit-verschillende-site-collecties-tonen-met-sharepoint-search-deel-3-sharepoint-search-web-parts-inzetten-om-content-te-tonen/ (in Dutch).
Leave a Comment