Creating submit forms in SharePoint

Yes, I know the title of this site is "SharePoint for the Non-Developer". That implies, to me, that this is for someone that does not code. Well, I had to enter the "developer" world.

A little background information...our "old" intranet had several submit forms where a user would complete the information, hit the "submit" or "send" button and the information on the form would be sent to an e-mail address. Until recently, we've been using InfoPath for these things. We have run into a few issues though. The biggest issue is our company does not have the Enterprise SharePoint license. If we did, we could have web enabled the InfoPath forms and we probably wouldn't have encountered the following issues.

Not only did we not have the Enterprise license, we also don't have a consistent image across the board. Some people have Office 2003, some receive the Office Suite via Softricity. InfoPath requires a local install, and the forms are really happier if they are InfoPath 2007. Oh, and some do not have InfoPath at all, and there is no plan for that to change.

All of this means InfoPath is not a good solution for our company when it comes to simple submit forms that do not require a workflow, but are simply meant for some form of feedback.

What now? Well, after much research I finally found a solution on http://www.codeproject.com/KB/sharepoint/SharePointContactForm.aspx

This is where I learned how to create a new WEB PART, yes web part, that is a submit form. this is written in C# and deployed with a .wsp just like any other web part.

If customized solutions that require code scare you, give this a try. Try it on a development box. Give yourself about two - three days if you have no Visual Studio experience just to fumble around. I had a little experience and it took me about a day - day and a half.

Happy SharePointing :)

Missing Content Editor and Summary Links web parts for our editors

Another day, another puzzle to solve. Today, our editors realized they didn't have the Content Editor web part and the Summary Links web part in their list of web parts that they can use. I'm sure there were others missing as well. These two just happen to be the only ones they know how to use. Same permissions as discussed in my previous post. Very similar resolution.

Read rights needed to be applied for all users to the Web Part Gallery. This is located under >Site Actions > Site Settings > Modify All Site Settings. Then under the Gallery section you will see "Web Part Gallery".

As with everything else I wanted to know WHY this had happened. Permissions had been tweaked as part of a clean up effort, but nothing was done directly to these specific lists. The only thing that I can come up with that makes sense is that when the permissions were tweaked, some rights were removed. SharePoint must have removed the rights from these lists as well. Now, we ended up needing to add those rights back because we took too much control away from our editors, but when that happened SharePoint didn't put the rights back on to these lists because at this point inheritance had been broken.

Is your head spinning yet? Mine is. It's all good and I really like digging in and solving these puzzles but WOW! Thing happen that you just can't anticipate.

Manage Heirarchy permissions and unable to create a page

Recently came across an issue where the "editors" of our intranet site were unable to create a page. The permissions they had were Manage Heirarchy, Approve and Edit. I had recently modified some permissions as part of a clean up effort and somehow all of the rights got removed from the Master Pages Gallery. Everyone needs READ access to this. Access is assigned at the top level. >Site Actions >Site Settings >Modify All Site Settings >. Under the "Galleries" section , select "Master Pages and Page Layouts".

This is one of the stranger things I've come across. I talked to a few others that have been doing SharePoint longer than I have and they hadn't come across this yet.

SharePoint redirector webpart based on Active Directory accounts

Our company intranet site has two audiences; home office and agents. The home office has different new content than the agent side. It's viewed as two separate intranets really, even though it's all in one site collection. Because of this we rely heavily on target audiences and redirects.

We hired an outside consultant to develop some custom webparts for us. One of those being a redirector webpart that would take Active Directory groups that we specified and redirect from one page to another. When it came time to implement this webpart it didn't work. I put it on the page and configured it but it simply didn't do anything. It was like the web part wasn't even on the page. After a 90 minute conference call with the consultant, and no progress I decided to take matters into my own hands.

There are several redirector webparts out there that make great promises. Some of them are code where you can cut and paste into Visual Studio, others are for purchase. I saw one for $500. I don't hold the purse strings where I work and since we'd already paid for a consultant to custom develop a web part I knew asking to purchase a different one wasn't going to happen. Then I stumbled upon this. (when you click, make sure you do a right click to open in new window, or you will navigate off of this page). It's a little piece of heaven.

This webpart uses the SharePoint people picker. This means, this is much easier for both myself and my end-users to use. No more remembering what the AD group names are and having to key them in just perfect. This searches and lets you select either the group or one user AD account you want.

The install is easy. Simply copy the .wsp file to the location you want to run it from, set up your stsadm commands in a batch file and run. Once you've done this, go to the site level and activate the feature. Now you are ready to add the web part to the appropriate page and configure it.