SharePoint Blogs

Overview

The current migration project I am working on is migrating a very large, 8 year-old portal and all its contents from an archaic BroadVision platform to MOSS 2007. BroadVision is absolutely one of the worst portal software packages I have ever seen, and is proving to be quite difficult to migrate into MOSS 2007. This is part 1 of an ongoing series of stories about this project and its challenges.

Migrating Forms

BroadVision has support for a crude version of custom web forms, that can be used to collect data and either email the data or save it in a database. These forms are standard html forms with html form tags, and almost all of them have a spot at the top of the form where some introductory html is placed to instruct the user on how to use the form, the form's purpose, etc. This project has about 200 of these forms, for almost every department in the organization.  These forms have very little workflow, with just some primitive options to email or CC people when new forms are submitted. There is no easy way to automate this migration.

Below is an example of one of these forms, which is a form to update an employee's address:

InfoPath vs Custom Lists vs ASP.NET Web Applications

The first decision to be made in migrating these forms is choosing the right technology. I presented 3 options to the customer:

• InfoPath - Pros: Flexible, supports validation, custom actions and workflows, can save data to sharepoint lists, libraries, and external databases. Cons: Requires training and design skills, and sometimes coding and development efforts
• Custom SharePoint Lists - Pros: Anyone can do it, easy repository for data, built-in export to Excel, Datasheet view, MOSS 2007 workflows. Cons: Limited validation support, little or no design control, data can only be placed in SharePoint
• Custom asp.net web application - Pros: Complete control over design and storage. Cons: Requires development effort

With over 200 forms to migrate, very little resources, plenty of new forms yet to be created, and lots of forms that need updating or reviews, the customer wanted every department to own, migrate, and create their own forms. The best solution in this case was the one that empowered the end users to create and manage their own forms as easily as possible.

For 90% of the forms, the custom list was the right approach, unless a form needed advanced features like validation, pre-population, etc. The only stumbling block then was having the ability to edit the form that is displayed when you create a new item (NewForm.aspx).

Introductory Text and HTML

Every form in the old portal had a space at the top where introductory HTML could be placed to provide instructions. Since a custom SharePoint list uses the default NewForm.aspx page when adding a new item, there is really no place where this intro HTML could be placed. To solve this, we used a special querystring to put the NewForm.aspx page into edit mode, where we could add a Content Editor Web Part above the form's contents.

Following is the method for getting this to work:

1. Go to the custom list and click the menus to add a new item.
2. On the New Item form, add a querystring parameter to the end of the url, and hit enter. For example, a typical New Item form's url might be:
   
   http://intranet/Docs/Lists/Tasks/NewForm.aspx?RootFolder=%2fDocs%2fLists%2fTasks&Source=http%3a%2f%%2fintranet%2fDocs%2fLists%2fTasks%2fAllItems.aspx
   
   Add the following text to the very end of the url: &ToolPaneView=2
   
   The new URL becomes:
   
   http://intranet/Docs/Lists/Tasks/NewForm.aspx?RootFolder=%2fDocs%2fLists%2fTasks&Source=http%3a%2f%2fintranet%2fDocs%2fLists%2fTasks%2fAllItems.aspx&ToolPaneView=2
   
3. This puts the page into Edit mode, and displays the Add Web Parts toolpane. Click Next until you see the Content Editor Web Part. Drag it into the Web Part Zone at the top of the page.
   
   
   
4. In the newly added part, click the link to open the Tool Pane ("To add content, open the tool pane and then click Rich Text Editor.") , and paste your introductory text into the Rich Text Editor. When done, click OK, your instructions are now live on the Form.

Granted, telling an end user to hack a querystring to add a web part is not the most user friendly approach, but it is certainly something that can be documented well, and is certainly easier than InfoPath training. Of course this step could also be done easily with SharePoint Designer, but that is another layer of complexity that the users don't need.

From time to time I need to elevate the permissions of a group of users. A recent example was when I created a FAQ discussion forum on our top level site in MOSS. Normally all our employees are visitors to the main site as we have special content managers for this site (it's a publishing site) but for this list they needed to be able to add content (contributor rights).

I've read a couple of different ways to handle situations where permission rights conflict like this and one golden rule I've heard is never to change the rights of a predefined group, such as giving visitors contributor rights. If you violate this rule you end up with a number of lists, sites and what have you where a visitor no longer is a visitor.

The "proper" solution, I would guess, is to create a new SharePoint group and call it "Contributors to this list" or some such, give it the proper rights and then add the users to this group. This is a rather cumbersome process though.

You could also add the users to the "Contributors" group but that would give them contributor rights to the entire site and that's a no-no - at least for me.

Lately I've found myself violating my golden rule more often than not by breaking permissions inheritance from the site the list resides in and then giving the orphaned visitors group the proper rights - simply because it's the easy way out.

How do you handle situations like this? Quick and dirty or by the book? Or maybe some other way?

               In one of our project, we are supposed to lock down the users from creating folders at ROOT in document library. We thought of restricting through event handler. During coding we found that, ItemAdding event doesn't provide enough information to determine where the folder is been added.

              Searching on net, we found that was the bug in Microsoft, and they have provided a hotfix. You can get the Hotfix information in the below URL. It not only solves this problem, but also couple of other bugs, which you can find it in this URL.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;934790

             After installing this hotfix, you will get the AfterUrl property is having the information to determine where the folder/file is been added. But be careful in installing this hotfix, bcose sometimes it might negatively affect your project. We faced a problem of 'Access denied' error message for accessing LOGS folder programmatically. So, testing the hotfix completely in a test environment is mandtory b4 installing on Development/Production machines.

 Satheesh Palaniswamy.