Working with SharePoint List Attachments

SharePoint Lists are a versatile artifact in SharePoint. It can be mend in any way possible to achieve the desired outcome. This is the reason to use List for all the help desk applications. Recently I had to build a helpdesk application but the client wanted to use plain vanilla SharePoint and wanted to avoid custom code and wanted to keep it to bare minimum. Building a simple helpdesk with List and no code is relatively straight forward but the catch here is they already had created a basic structure where they are using a list to collect the information from external users and the information is getting copied to a new list for internal users. This is done to implement separation of permission as mentioned earlier there is no code approach. This is in their POC environment.

Now they wanted to move to production.Implementation is done as follows

1. They are using attachments in the list to get relevant reference documents form external users.
2. Workflow is been used for copying item from one list to other.

The problem that they are facing is attachments are not getting copied. This is interesting because attachments in SharePoint lists are a linked item and is not part of the SharePoint fields. This is what is causing the workflow not to copy the attachment. Also there is no workflow activity that can copy attachment.

The way to solve this problem would be to

1. Create a custom Copy List Item activity with extended functionality to look for attachment and copy it.

2. Customize the List form with Infopath forms and make the attachment to be part of the list item (This I saw working but still could not comprehend why it works.)

3. Write a small event handler (Item Added and Updated(if you are allowing delayed submission) and copy the attachment.

We went with third option and reason for that being though we had to write code we could do it on a Sandboxed solution rather than a Farm solution which would be the case for option 1. Option 2 is ruled out because the client did not like infopath forms. Its good because we now know Infopath form is dead you can read this here)

There is another thing the remember with List Item  attachments. Since List Item Attachments are  stored as collection when you access them in code and these are collection of strings rather than a file. so we have to user getfile method to get the file and add it. Similarly adding an attachment do not need item update as it linked item.

Client is on SP 2010 and I had not  an opportunity to try this out in Client Side Object Model (CSOM or JSOM) which I am planning so that it becomes easy for SP2013 but will update this post after trying with SCOM/JSOM code.

Code :

foreach (string fileName in requestItem.Attachments)
{
  SPFile file =requests.ParentWeb.GetFile(requestItem.Attachments.UrlPrefix + fileName);
                                   properties.ListItem.Attachments.AddNow(file.Name, file.OpenBinary());
}

Set Field Created through UI to readonly

SharePoint fields are excellent form of reusable asset. There are different types of fields that can be created in the SharePoint environment. As a developer we tend to create some fields as readonly which we could achieve easily while creating the solution using FieldXML in the element.xml file. But there are time when we had to create fields from the SharePoint UI which do not provide the flexibility of setting the field readonly. We would come across these scenarios when we want to have a field that will be used in Workflow or even some times we do not what to show the fields in Edit and Newform of the list or library. It would be an overkill if we create a solution for deploying a readonly field.

There is always poweshell who is our best friend who will never let us down in need. A small script would help achieve this. Below is the script that I wrote to set a list field to readonly.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

#Get the Web

$web = Get-SPWeb "http://sp2010"

#Get the List

$List = $Web.Lists["Daily Email"]

#Get the Field

$Field = $List.Fields["Email User"]

#Set the field to Read only

$Field.ReadOnlyField = $true

$Field.Update()

Note that I am using Display name of the field instead of internal name. Please feel free to extend this  script if you like. Also make sure you are running this script as Admin user.

I will share the next thing I experiment and until then Happy SharePointing.As always if you have any suggestion or question feel free to ask in the comment section so we all can learn together.

Death of Infopath Forms

Infopath forms has been both blessing and pain at the same time since SharePoint 2007. With the growth of new web technologies, we always wonder is there a place for infopath forms in SharePoint universe. The inherent limitations and clumsiness of infopath forms has finally come to an end. Yesterday the office team has clearly elaborated on the course of infopath form going forward.

InfoPath, though a useful tool for customization on SharePoint it always lacked functionality which prevented it becoming mainstream. So the verdict is finally out and it is death of infopath forms and there will not be any future releases of infopath forms beyond 2013.

Let us hope that Microsoft comes up with really cool forms interface and development environment soon.

Happy coding and RIP Infopath we will definitely miss you if not a lot may be little.

PS. is there any acquisition by Microsoft (K2 or Nintex).