Guest Author: Jason MacKenzie
Intelligence Among Us

In the first post in the series I wanted to spend some time laying the groundwork for our search solution so there is a shared understanding about why things were organized in the way they were. As I mentioned in the last post, the purpose of the search solution is focused specifically on helping users locate and manage electronic forms.

A new web application was created to host the forms and a single site collection will be used to hold all the sites that contain the completed forms. The root site will contain a list called the eForm Catalog which serves two main purposes. The first is as the source of data for all our search related functionality and the second is as a working list for our Business Analysts to manage the information about the forms. I’ve included a screen shot so you can get a sense of the information that is being managed about the forms

A search site has been created under the root site of the site collection which will serve as the landing page for all the eForms users. A somewhat simplified view of the site hierarchy can be seen below.

A content type was created called eForm that derives from Form. This content type has three columns: eForm Status, eForm Name and eForm Open/Closed. All published InfoPath forms will inherit from this content type and I will demonstrate, in future articles, how we will use this to facilitate searching.

While it’s not really germane to the topic of this series I wanted to explain why the sites are structured as they are. The intention is that users will interact with the forms from the search page without the need to directly navigate to any of the subsites to view their forms. The departmental sites are used to logically store related forms as well as to provide a container for storing configuration lists that are used to populate the InfoPath forms when they are opened. All InfoPath form templates are stored in a library in the root site of the site collection.

The first issue that we need to take a look at is the fact that we want the users to be redirected to the search page. You could put a simple redirect script on the home page of the root site but that would redirect everyone. The BAs and some other administrative users need to access the eForm Catalog on the root site and while they could simply bookmark the URLS they tend to be a whiney lot. So we created a SharePoint group called eForms Administrators and placed the appropriate users into it. Now we can use SPServices to selectively redirect anyone who is not a member of this group. Place a Content Editor Web Part on the eForms home page and place the following script into it (make sure to add your jQuery reference as well):

<script>
$().SPServices({
      operation: "GetGroupCollectionFromUser",
      userLoginName: $().SPServices.SPGetCurrentUser(),
      async: false,
      completefunc: function(xData, Status) {
               if($(xData.responseXML).find("Group[Name=eForms Administrators]").length == 0) {                                location.href = '/search';
        }
}
});
</script>

The other issue we needed to deal with was the fact that our eForm Catalog serves 2 purposes. We need to let the BAs work on it while it serves as the source of data for our search. To do this we used a SPD workflow and the Useful SharePoint Designer Workflow Custom Activities project to manage the permissions. If you remember from a previous article I had discussed the idea of creating an eForm Locator content type. After further discussions with our BAs we decided that since they needed a list where they could track metadata about the eForms as part of the migration project, that it didn’t make much sense to have 2 lists containing some of the same information so they were combined into one.

The eForms Administrators group contribute access to this list. When the status field is changed to “Production” the workflow will grant Read access to all authenticated users. This means that our search results, tags etc. will be automatically trimmed by SharePoint’s native security so that only forms that have a status of “Production” are returned in the results. See below for a screen shot of the workflow:

Now that I’ve explained the foundational pieces of the search solution, I’ll start focusing more on the specific pieces of functionality in future articles. Enjoy!

Guest Author: Jason MacKenzie
Intelligence Among Us

Jason has been an IT professional for 12 years and has worked in a variety of roles from software development to managing business solutions for a large international automotive supplier. He has developed mission critical software solutions for the manufacturing industry and has experience in the government and educational fields as well.

Jason is a social networking enthusiast and is currently working as an independent SharePoint architect. Jason helps organizations with strategy and implementation guidance related to architecture, governance, processes as well as hand-holding and facilitating a good group cry every now and again. Jason’s goal is to actively participate in the community and share what he has learned in order to help people and business leverage their investment in this critical platform.