I recently completed what I estimated to be a small project of taking an existing set of InfoPath forms that represented Content Types and Site Columns for a client's yearly employee review process.  Last year they had to manually create a number of forms for each employee to be filled out and eventually sent to Human Resources.  If each employee has an average of 6 forms (they do peer reviews) and a manager is required to pre-fill each form and manage the permissions of said form for each employee, a significant amount of time is wasted. 

I estimated that in about a week or two we could write a web part to collect all the data, load up and pre-fill each form's XML, add it to the doc library, and set the permissions for the forms throughout their lifecycle based on the current status of the review process.  It will take too long to go over the whole project/code-base, so I'll highlight the important areas.

1.   Web Part to collect employee, supervisor, reviewer users and some dates, etc.

2.  Event Handler on the form library to look at the status as updated by the form upon submit.

Problem 1:

I thought I could be clever.  Knowing the XSN generated from InfoPath contained the underlying XML file I would need to populate and save in SharePoint, I thought I could use the foundation from this blog post to get to that file:  http://www.kindohm.com/archive/2008/01/10/programmatically-create-an-infopath-form-instance-from-xsn-template.aspx

It is a great concept, albeit a little hokey.  The basic concept is to use the XMLFormView control to load an instance of an XSN, then extract the XML from it and use it.  The problem is that you can't get the control to initialize unless it is actually run in a page.  So, the poster put the form in another aspx page and calls it via his code (in my case the web part) through the WebClient or HTTPWebRequest and return it as a Response Type of XML.  This solution works great in Windows Server 2003, but Windows Server 2008 it only throws 401 Unauthorized errors.  It tried everything, every different type of credential I could.  The only time it worked in Server 2008 is when I used the default app pool in IIS, and it has some different settings (Network service account, etc) that I wouldn't want to use for MOSS.  At any rate I could not get around this problem even after hitting up some MOSS MVPs that I have tremendous respect for.

Problem 2:

I worked around Problem 1 (hopefully temporarily) by saving my InfoPath forms as source files and manually dropping a copy of the XML container in the form library where the XSN lives.  This created Problem 2.

If you create your InfoPath form on your local machine, the resulting XML does not share the same XML processing instructions as those that are created when publishing to a SharePoint library.  So, I had to manually replace the instructions in each XML file as it was created.  I had to use scientific method to find out which instructions were causing the form to load improperly, but it came down to these two items:  href and solutionversion.  Href is obvious, the xml needs to point to the library that is hosting it so Forms Server knows where to process the form.  Until it is published to the library this value is not set, so I had to set it by hand.  Code snippet below:

Solutionversion turned out to be completely obnoxious.  By default, the solution version in the "save as source" XML is exactly 3 revisions ahead of the one published to SharePoint.  So I needed to manually decrement my XML file so Forms Server could properly load it: 

Since processing instructions are just whole single nodes, I couldn't easily just replace individual attributes.  Instead I had to grab the existing entire node and replace those elements I needed to update via string manipulation, delete and re-add my new processing node back into the XML.  This all seemed to work, and can be completely removed if I can get the security issue in Problem 1 fixed at a later time.

Problem 3:

This problem isn't specific to InfoPath or this solution, but has come up enough that some people new to this game should be aware of.  If you want to give a set of users rights to add items to a document library, but then only see and manage their own items, you can't do it.  It works fine with standard lists (an advanced setting on Lists) but this was left out for Document Library and child lists.  Why?  I'm not sure. 

It certainly makes it difficult on projects such as these where you need to assign users certain items, and list item permission by hand can be tedious and error-prone. 

My common solution to this problem (when I don't have workflow as my manager of the data) is to use an event handler on the list to look at the appropriate metadata and content type and determine what needs to happen.  It is sort of a mini rules engine for permissions processing and it looks like this:

First, override your events (ItemAdded and ItemUpdated for example) and check the Content Type: (feel free to use more descriptive terms, the names have been changed in my code to protect the innocent)

Here is what the permissions setting code looks like:

This code is pretty straightforward except for HandleEventFiring which is something none of you have seen before,  This is a custom class I created to handle versioning issues on list items, etc.  My full blog post about how and why I use it is here:  http://blogs.syrinx.com/blogs/sharepoint/archive/2008/11/10/disabling-event-firing-on-splistitem-update-differently.aspx

And finally, the code to set the actual permissions:

That's my solution for one way (without custom workflow) to manage document permissions to allow everyone to contribute, but then lock down the documents upon creation and updating.

Problem 4:

Another concern with InfoPath I ran into was publishing updated forms to SharePoint and mapping fields to site columns.  InfoPath supports creating site columns locally and mapping them to it's local XML data fields to be updated automatically upon submission. 

Upon publishing changes to a test environment I didn't realize that it is possible for these fields to get out of sync.  InfoPath protects itself by creating brand new site columns with the same name.  From the SharePoint UI and InfoPath perspective everything looks great until you see your column names showing up twice in list management and view creation screens.  Your code also starts breaking as it's looking for a certain internal name that is no longer being populated.

Basically SharePoint just creates a new site column with the same display name, but creates an internal name like columnname1 or columnname12.  The fix for this is DON'T DO IT IN THE FIRST PLACE.  It is a pain to hunt down the correct columns and delete them (after deleting your content type form because of the "in use" issue) 

Instead, at this screen:

Click "Modify" and make sure the local field is mapped to your correct site column.  If you see (none:  create new site column) you need to change it unless this is a brand new field.

The screen below shows how to "re-map" to an existing site column created by InfoPath:

Well, I know this post was long, and it didn't cover everything I did, but I tried to cover the parts that caused me some hang-ups.  Despite losing 2.5 days alone to the security problem I still was able to deliver the mini-project on time.  There were some things I would have much rather done differently, but due to the issues and time constraints I had to get something out there and working.

I hope this helps,

-Ryan Thomas

Read the original blog entry...