Is it possible to filter my search results in sharepoint 2013 to only return items that a user is following (sites, documents, etc).



I finally was able to create a client-side solution that addresses your requirement! Roughly put, I don't think out of the box there is currently a way to filter on the followed items, based on the documentation on search query variables at https://technet.microsoft.com/en-us/library/jj683123.aspx. Ofcourse one can build a server-side webpart that extends the out-of-the-box ones, but this is a non-supported scenario for SharePoint Online.

Therefore I have been playing around with the content by search and search results webparts to see if it is possible to inject the followed sites query statement into the query before it is ultimately executed; using the Content Editor / Script Editor injection pattern (see a great post by Vesa Juvonen).

(scroll to the bottom to find a link to a gist with the integral Content Editor / Script Editor include file)

I have found two approaches:

  1. Extend $create (Microsoft Ajax) and the obscure Srch.ScriptApplicationManager.prototype.$4b_1 (search.clientcontrols.js; which msdn does not have any documentation for);
  2. Extend Microsoft.SharePoint.Client.Search.Query.SearchExecutor.prototype.executeQueries (sp.search.js; see partial documentation on msdn) and SP.ClientRuntimeContext.prototype.executeQueryAsync (sp.runtime.js; see msdn).

Ad 1. If you review the aspx content that is generated by the search webparts you will see that it contains some $create (Microsoft Ajax) statements that create the search client objects during the initialization of Sys.Application (Microsoft Ajax). There is a specific Srch.DataProvider (also within search.clientcontrols.js) that is instantiated with the query you want to modify. Unfortunately it is not trivial to extend synchronous execution with an asynchronous request to retrieve the required data, i.e. the followed sites of the user. Eventually you will end up also replacing this obscure $4b_1 function that forms the heart of the Srch.ScriptApplicationManager lifecycle. I have not found a better way to intercept the flow! I first tried to intercept the instantiation of Srch.ScriptApplicationManager, but this is not fully possible through the Content Editor / Script Editor webpart pattern: when other search webparts on the page include display templates, those are loaded before our code loads, and already trigger the instantiation of Srch.ScriptApplicationManager. Maybe it is possible to load code before the display templates are loaded, for example by using scriptlink custom actions. I haven't investigated this further.

Ad 2. Since approach 1 contains the replacing of an obscure function, I continued looking for another way that only uses non-obscure function extensions. By stepping through the whole flow I found out that it ultimately uses the executeQueries client-side object model api to retrieve the search results. So summarized solution 2 does the following: it intercepts the calls to executeQueries, defers the executeQueryAsync that follows, gets the followed sites, injects them into the pending query, and finally executes the deferred executeQueryAsync. The search webparts just think they were waiting on the original query results! I have published the integral Content Editor / Script Editor include file as a gist over here: https://gist.github.com/cveld/4e2991babb3dc595532f

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.