Monday, January 14, 2013

Document Sets in a SharePoint 2010 Library Template

Recently I needed to create a SharePoint Library template w/ content for a client. They had over 300 document sets with 3 metadata fields that they wanted inside the template. Each year they needed to create a new library with this exact same layout, so saving a document library as a template seemed like the perfect fit.

I created the library, created all the document sets and setup all the metadata for each one and then saved that library as a template.

Unfortunatey when I created a new library based on my shiny new template, all the document sets were generated as Folders and errored out when I tried to access them. Once I manually changed the content type from Folder to my Document Set content type, all worked fine and all metadata fields had the proper values.

So this lead me to research how I could quickly modify over 300 folders content types to the Document Set type.

I then stumbled on this great article by Phil Childs on Changing the Content Type Set on Files in SharePoint.

This PowerShell didn't quite do what I needed it to do however, as it was just looking at the Items and not the Folders, so I modified it slightly to produce what I wanted. My change required creating an array of the Folders IDs as updating a folder changes the collection and would error out of a ForEachObject loop.

Here's what I came up with:
function Reset-SPFolderContentType ($WebUrl, $ListName, $OldCTName, $NewCTName)
{
    #Get web, list and content type objects
    $web = Get-SPWeb $WebUrl
    $list = $web.Lists[$ListName]
    $oldCT = $list.ContentTypes[$OldCTName]
    $newCT = $list.ContentTypes[$NewCTName]
    $newCTID = $newCT.ID
    
    #Check if the values specified for the content types actually exist on the list
    if (($oldCT -ne $null) -and ($newCT -ne $null))
    {
        #Go through each item in the list
	$folderIds = @()
	$list.Folders | ForEach-Object {
		$folderIds = $folderIds + $_.ID
	}
	ForEach ($folderId in $folderIds) {
            #Check if the item content type currently equals the old content type specified
	    $item = $list.GetItemById($folderId)
            if ($item.ContentType.Name -eq $oldCT.Name)
            {
                    #Change the content type association for the item
                    write-host "Resetting content type for file" $item.Name "from" $oldCT.Name "to" $newCT.Name
                    $item["ContentTypeId"] = $newCTID
                    $item.Update()
            }
            else
            {
                write-host "File" $item.Name "is associated with the content type" $item.ContentType.Name "and shall not be modified"
            }
        }
    }
    else
    {
        write-host "One of the content types specified has not been attached to the list"$list.Title
    }
    $web.Dispose()
}

To use it, you copy the entire function, open a SharePoint PowerShell command prompt and paste it in. Hit enter until the >> is no longer you prompt. Then you can use the function like so:

Reset-SPFolderContentType –WebUrl “http://sharepoint/sites/audit” –ListName “2002” –OldCTName “Folder” –NewCTName “Audit Document Set”

Thanks Phil!
- Owen Runnals
SharePoint Practice Manager @ General Networks Corp

Saturday, January 5, 2013

The future of custom forms in SharePoint 2013

I've been doing quite a bit of research on SharePoint 2013 and the future of custom forms. Back in SharePoint 2010 the push seemed to be toward InfoPath Form Services and using IP to create your forms (items, workflow initiation, tasks, etc...).

At the SharePoint 2012 Conference there seemed to be a big push toward Business Users using Access 2013 to create their custom forms, but after I got my environment setup for this I quickly found out that this certainly doesn't replace InfoPath. An Access Web App is very powerful, however it doesn't really integrate with SharePoint other than being hosted there. You can't have workflow run on your items, and you don't even access SharePoint lists or libraries (the data is stored in SQL by the app).

The lack of attention to InfoPath at the conference as well as a few other things (listed below) have made me wonder... What is going to be the InfoPath replacement?

Reasons I believe InfoPath is going away:
  • InfoPath forms services doesn't work with Forms Based Authentication or SAML Tokens. I've been told by Microsoft that this isn't going to change, which leads me to believe they are not putting a focus on it. (See "Features that do not work with forms-based authentication or SAML security tokens" here: )
  • SharePoint 2013 removes InfoPath Forms for Workflow Initiation or Tasks.
  • The complete lack of attention at the conference to InfoPath along with a focus on CSOM and custom ASPX pages.
  • The fact that they haven't fixed things like mapping People Selector fields to actual people columns in Form Libraries, and the ability to access Managed Metadata in custom InfoPath forms. This was frustrating in SharePoint 2010 and is the same in 2013...

So, where does this leave us? Here are the options as I see it:
  • Access Web App - If it's business users and they don't need workflow (like a LOB solution) this could be a great solution.
  • Custom ASPX forms - At the time of writing this seems like the way everything is moving. Strangely this moves form design out of the businesses hands (the push was the opposite way with 2010 release) and into the developers hands.
  • InfoPath - Still fully supported in SharePoint 2013, however as I mentioned above, reading between the lines tells me this may be the last release that "fully" supports IP, so it might be time to start new projects with one of the above two options.

In the end I feel custom ASPX pages are the safest bet since they've worked since SharePoint 2007. Who knows where Access web apps will go in the future. Only time will tell.

As I learn more I'll update this post.

- Owen Runnals
SharePoint Practice Manager @ General Networks Corp