Relationships between site directory, search, and WSS team sites
I was asked recently if there was a web part in SharePoint that would display all the team sites where the current user was a member. My immediate push back was what did it mean to be a member? I began down a path investigating the relationship between team sites, the site directory, and search as well as some custom dev for the above web part. I just thought I would record some interesting observations:
For reasons that I'll explain a bit later, I first wanted to make sure that my WSS team sites were in the search catalog of my SharePoint portal. You should know that I have an environment where there were WSS team sites in a virtual server that was separate from the SPS implementation. This turned out to be a good thing as it opened my eyes to some important details. Almost everyone knows that when you run the "Create Site" link from the Site Directory of a SPS Portal, you get a checkbox to include the site in the site directory as well as a checkbox for the team site to be included in search results. It is IMPORTANT to realize that these are two separate requests. Most of us run as administrators and don't see the approval that is required behind the scenes for both of these actions. I had even a bigger dilemma, my WSS sites were in another virtual server. How could I get these team sites in the search catalog?
So you might think that you would just add a new content source. You of course would be wrong. If you add the team site as a web site content source, the index search engine wouldn't be aware that it was a WSS site and would not have access to features like being security aware. The trick here is in the admin of the portal, in the search settings and index content portion, there is a link to "manage crawls of site directory". What is quite interesting is that this admin area really has nothing to do the site directory of the SPS portal. This admin area shows you the WSS sites that users have created where the checkbox to include in search results has been selected. From here, I could add my WSS sites in the other virtual server.
So why did I dive into search. Well to meet the request of displaying all the team sites where a user has access, I could think of 3 different approaches: query the database, enumerate the object model, or use the search catalog. Querying the database would be easy, but I would be opening pandora's box. Who knows what a service pack might do... Plus creating a security aware list would be more difficult. Enumerating the object model would be easy to code and security aware, but execution time would be a problem. Especially if the customer came back and said that they wanted a list that included subsites as well as top-level sites. Using the search catalog gives me a security aware data store (users only get search result items that have access to) that I can query rather quickly. I threw together a QueryTester web part that uses the QueryProvider class to execute any search query I give it (this.Text). Here are some of the highlights of that web part's code:
if (this.Text != String.Empty)
PortalContext context = PortalApplication.GetContext();
query = new QueryProvider(context.SearchApplicationName);
DataSet results = query.Execute(this.Text);
grid = new DataGrid();
grid.DataSource = results;
So the following query would return the list of all team sites and their subsites that the user has read access to:
SELECT "DAV:contentclass", "DAV:displayname", "DAV:href"
WHERE ("DAV:contentclass"='STS_Site' OR "DAV:contentclass"='STS_Web')
So now I will have to go back to my SPS Automation article and add code to include the add to search and site directory actions!