Moving documents from one document library to another maintaining versions - SharePoint 2010

Hear is a simple task - Move documents from one library to another in SharePoint 2010 Document Library. Sounds simple! You can use "send to another location", "explorer view" etc. etc. But let me slightly complicate things here -

Move documents from one library to another in SharePoint 2010 maintaining all versions of the document in the new library.

Now, there is an understood pre-condition associated with this task that both libraries should have versioning enabled to the same level (minor or major).

What I found was that, when we use "send to another location" or any other OOB method to transfer the document from one location to another, versions are not maintained. They are simply forgotten. Reason for this is simple - at the new location, even though versioning is enabled, the transferred (moved) document is the very first version. In simple words, versioning is initiated at the new location only after the document is created there.

But as usual this was something I did not expect, because all my client asked is to move documents from location A to B and I very confidently agreed to do it in a few minutes time. And as a P.S. the client added that documents have versions and versions will be required at the new location. I thought - "That should not be a problem??"

Turned out I was wrong. I panicked and the first thing came to my mind was "custom code" and the pain it would cause to write all those lines, build, debug, test; build, debug, test; build, debug, test... you get the point.

But then, a little bit of researching gave me this quick solution -

All you need to do is open both locations (document libraries) in explorer view and cut and paste the files to the new location. Note that -

1. Copy and paste will not carry your versions,
2. Both location should have versioning enabled and
3. Both libraries should have the same template i.e. document library --> document library or form library --> form libary and so on.

Really neat trick and saved a lot of my time. Huh! Can spend some time playing angry birds now!

"I cannot delete this column from my list??" - Well that must be a SharePoint 2010 Peristent column

If  you are viewing this blog post I assume you have not had a very good day at work today! Here's a look at what happened to me -

I recently ran into a problem where one of my users added a site column called "Target Folder" to their SharePoint list and later realized that that column was not required. So the user wanted to delete the "Target Folder" column. That is the most basic SharePoint task that is there to be done and so I wondered that why is this user coming to me for something so trivial.

Alas! Everything in SharePoint is not what it seems. I went to the list settings clicked on the column and I could not find the delete button in fact I could not find any means to edit that column. What happened here? I checked some other columns (Had my farm gone crazy?) No! Every other column in that list (or for that matter in the site) seemed absolutely fine.

After a few hours of digging here and there I turned to Master Google and I was enlightened!

There are a set of site columns which are Persistent site columns and once added to a list these columns cannot be modified or deleted (through the SharePoint UI). Also, if you add these site columns to a custom site content type you will not be able to delete the site content type as well. On attempting to delete the site content type you will get an error stating - "The content type is in use and cannot be deleted" even though you have not used the content type anywhere.

Here is a list of site columns which are persistent:

1. Active
2. Aliases
3. Article Date
4. Byline
5. Contact
6. Contact E-Mail Address
7. Contact Name
8. Contact Picture
9. Custom Router
10. Image Caption
11. Page Content
12. Page Icon
13. Page Image
14. Priority
15. Properties used in Conditions
16. Property for Automatic Folder Creation
17. Rollup Image
18. Route To External Location
19. Rule Name
20. Scheduling End Date
21. Scheduling Start Date
22. Submission Content Type
23. Summary Links
24. Summary Links 2
25. Target Audiences
26. Target Folder
27. Target Library
28. Target Path

Be very sure before adding these columns to your list or content type.

To delete these site columns from your list you will need to do so by using PowerShell commands as follows:

$web = Get-SPWeb (Your site URL)
$list = $web.Lists[(Your List Name)]
$field = $list.Fields[(Your Column Name)]
$field.AllowDeletion = “true”
$field.Sealed = “false”
$field.Delete()
$list.Update()
$web.Dispose()

And.. I hope the rest of your day (if left) is nice!

There's a BUG! There's a BUG!! There's a BUG in the Discussion Board

This is something fishy!
Recently I was working with discussion boards in MOSS 2007. All seemed well. I had to create a simple discussion board with approval. "No big deal!", "That's non-IT stuff if you use SharePoint!"....... If this is what you feel you are in for a BIG surprise........ (just like I was :-) )
So I went ahead and created a Discussion Board, went into versioning settings, selected "Require Content Approval" and did a few test runs. Everything seemed to be working fine until I tested with different users.
Problem: User X writes a new post. This post goes for approval to User A. Until User A approves the post this post will not be visible to all the users. So the obvious thing to do is for User A to approve which he does but as soon as User A approves the post, User A's name starts appearing everywhere in the post viz-a-viz in the quoted text section, the picture of the person who started the thread. And poor User X who actally started the post is lost.
Reason: Now, when User A approves the post, he/she becomes the user to last update the post i.e. the modified by column of the post is updated to User A. And it so happens that in the flat or threaded view of a discussion the name of the user who last modified the post is displayed. But in our "content approval" case it sends a very wrong message. If you go back to the subject view to see the entire list of threads you see that the User X is still the creator of the post.
Now what: I had posted a question on MSDN forums, this is the link. I was not too satisfied with the answer. It stated to write an event receiver to update the modified by column of the post back to the created by column..

I wish there was a better way.... 

Copying Multiple User Field from one SharePoint List to another

So once again I landed up in trouble because of the Person or Group field (Multiple Selection). Refer earlier post.
Now, this time what I needed to do is I simply needed to copy a Person or Group field with multiple selection enabled to another such column in another list, through an Event Receiver.
You might think - "Why is he writing an event receiver?? Why can't he just use a simple SPD Workflow??"
But as usual.......... there is a catch!!
I have created a SharePoint site with Forms Based Authentication (FBA). My users no longer come from the Active Directory, they come from an SQL Membership API database.
And.... SPD Workflows run under the OWSTIMER.EXE service not the w3wp.exe service.
(For general information the w3wp service is created by the IIS and is used to handle web requests coming to a web server. The OWSTIMER service is created by the Windows SharePoint Timer Service and is used to execute scheduled jobs of SharePoint.)
So, since the SPD Workflows run under a different service, they cannot read the web.config placed under the IIS Service, therefore, they cannot read the Membership API database settings, therefore, SPD Workflows cannot identify FBA users.
So, I write a little bit of code to perform the task at hand i.e. copying multiple users from one column to another (using event receiver).
But again..... things are not as simple as you think. I write this line of code:
oDestinationList["MultiUser"] = oSourceList["MultiUser"];
here

• DestinationList is Destination List object
• SourceList is Source List object, and
• MultiUser is the name of the field

but this simple line of code doesnt work. It states that the source and destination objects are not of the same type and cannot copy code!!!! Why????? I have no clue!
On googling I found a long procedure for copying multiple user fields: Create a SPFieldUserValueCollection object and append user names in this object etc.etc..... thats too much work...
So, on doing a little bit of research I found that there IS a simpler way of achieving this. Here's the code:
oDestinationList["MultiUser"] = Convert.ToString(oSourceList["MultiUser"]);
and it worked!!!! Hurray!!!!
Really SharePoint is funny!! :)

Send E-Mails to SharePoint Multiple User Field SPD Workflow

I faced a recent problem whilst designing declarative workflows in SPD 2007:
It sounds pretty simple - I needed to send mails using the Workflow to users who were stored in a Person or Group field.
You might think - "What's the big deal in that??".... But here's the catch. The Person or Group field I am referring to allowed multiple user selection.
==Bam==
All hell broke loose. How was this possible??? The Person or Group field just doesn't show up in the Workflow lookup! What do I do? Will I need to write an event receiver? Ohh!!! I didn't want to write code here? It seemed so simple. But wait..... lets try to fool SharePoint.
OK so first I do not allow multiple user selection in my Person or Group field. (You might think what about the already existing records? Data loss! Ya I know.... you might have to do this the hard way - Create a template for your list including content, recreate your list using the template you just created and after finishing all the steps mentioned here add all the entries again..... I told you this was the hard way!)
OK continuing with fooling sharepoint...... now, on preventing multiple user entries my Person or Group field starts appearing in the Workflow lookup for sending mails.
I complete my workflow steps, go back to my list and again allow multiple user selection in my Person or Grop field.
Now lets check whether the workflow is giving any errors.....
No......... no errors! Congratulations! SharePoint has been fooled! (Now can re enter your entries as I had mentioned above)
Happy SharePointing! :) 

Blogs about SharePoint

Hi All,

I have created this blog exclusively for recording my experiences with SharePoint.

This is only a subset of my blogs. You can find all blogs at My Blog