Delete current minor version of a document

Case

There is a document already published to 1.0 and a user has accidently created a draft version 1.1. This new minor version must be deleted so the document is back to version 1.0.

Investigation

In this particular case the version history contains the following versions: 0.1, 0.2, 0.3, 1.0, 1.1. There is no way to delete versions 1.0 and 1.1 neither using the UI nor programmatically. They both have IsCurrentVersion=True and trying to delete any of these two versions throws an exception clearly stating that a current version of a document cannot be deleted.
After failing to delete it programmatically I tried by unpublishing version 1.0 but that doesn’t solve the problem because version 1.1 is still there.
After some experiments with the library settings I found a workaround to bring the version history as it was before creating the minor version 1.1.

Solution

By temporarily disabling the versioning for the document library I was able to modify and bring the version history as it was before.
This solution only works if there is only one draft version, in our case 1.1. If more minor versions are created (1.2 or more) then this solution will not work.

For demonstration purposes let’s say the version history for a document is: 0.1, 0.2, 0.3, 1.0, 1.1. We want to delete 1.1 and keep the other versions.

Steps:

  1. Disable versioning for the library
  2. Checkout and check-in the document
  3. Turn the versioning back on. Version history now is 0.1, 0.2, 0.3, 1.1
  4. Unpublish the document. Now the Unpublish option is available for 1.1. (After this step the version history is 0.1, 0.2, 0.3, 0.4)
  5. Checkout then Major-check in the document. (After this step the version history is 0.1, 0.2, 0.3, 0.4, 1.0)
  6. Delete the minor version created in step 5 (In our example version 0.4). (The resulting version history: 0.1, 0.2, 0.3, 1.0, i.e. same as before 1.1 has been created)

If the contents of 1.0 and 1.1 are different then before performing the steps above save the file version 1.0 locally and uploaded it to the library after step 4.

On a production environment it’s important to choose a proper time to perform these steps when no user is working with the library otherwise they may create major versions by accident during the time when versioning is off for the library. For more information how temporarily disabling versioning affects a list check my other post Effects of temporarily disabling versioning for a SharePoint document library

If you have event receivers registered for the document library you may want to remove them temporarily if you don’t get the behaviour explained in the steps above. To remove and add back the event receivers for a list check my other post Add, Modify or Delete List Event Receivers with PowerShell

Advertisements

Unable to edit document properties using the Edit form.

Problem

For some documents users are unable to edit document properties with the Edit form.

Case

A document library in SharePoint 2010 contains Word documents. Users open the Edit form by clicking ‘Edit Properties’ in ECB menu and change the values of the fields. When clicking Save button the form is submitted successfully without any error but the changes are not saved.

The problem is present for most of the fields but not all the fields. Name and Title can be changed for all the documents.
This happens only for some docx documents.

Investigation

First I tried to edit the properties of the problematic document so I can check for any errors. No error is thrown and the edit form is submitted but the changed field values are not saved. Not errors registered in Event Viewer or ULS logs.

I saved a copy of one of the problematic document and uploaded it to another new library. The document’s properties still can’t be edited. So this is not related with the document library.

I created a new document and I could edit the document’s properties without any problem. I opened the problematic document, copied its content and pasted it in the new document that was working fine. After this the new document is having the same problem and no custom fields could be edited with the list’s edit form. So it is clear that the content of the document is the problem. I started to remove the document content piece by piece and test the result. It turned out that hyperlinks to network shares in the document are causing the problem. As soon as I remove the hyperlinks to network paths from the document content the problem is gone and I can edit the document’s properties.

Tested by adding a hyperlink to a network share in a new document and the problem is not present. So the hyperlinks are not always the problem but only in the old problematic documents.

I discovered that the problematic documents have been originally created with Word 2003 as .doc files. The .doc files have been converted to .docx documents and uploaded to the library. I converted one of the affected documents back to .doc and re uploaded it. The problem was not present and I could edit the properties of the file. As soon as I converted it to .docx again the problem was back.

It’s clear that it has something to do with how hyperlinks to network paths added in a doc file are converted when converting a doc file to docx file. One way to fix it is to open the docx file and remove and re-add the hyperlink with Word 2007 or newer version.

There were thousands of documents in the library and probably many of them converted from doc to docx before they have been uploaded to the document library. There were just few document discovered that had this properties editing problem. Fixing those few problematic documents by opening them and remove then re-add the hyperlinks in the content was acceptable but there was a possibility that more documents will be discovered in the future and fixing manually every one of them would not be a very good solution.

I copied one of the problematic documents and tested it in 9 different farms with different SharePoint build version (from 14.0.4762 to 14.0.7116.5000). In three of the farms the problem was present. In 6 of the farms the document was not having the problem and I could edit its properties. All of the three farms with the problem were with different SharePoint build version but all of them had installed Cumulative Update of April 2012 before. The other farms without the problem had older build versions or much newer build version (SP2 and up). To discover which Cumulative update introduced this issue and which CU fixed the issue I performed the test with one VM with SharePoint build version prior CU April 2012. Here are the results:

  • Initial build version: 14.0.6117.5002 (February 2012) Test result: -issue not present
  • Installed CU April 2012, version 14.0.6120.5006 Test result: –issue present (introduced with this CU)
  • Installed CU June 2012, version 14.0.6123.5000 Test result: -issue still present
  • Installed CU August 2012, version 14.0.6126.5000 Test result: -issue still present
  • Installed CU October 2012, version 14.0.6129.5003 Test result: -issue still present
  • Installed CU December 2012, version 14.0.6131.5003 Test result: -issue still present
  • Installed CU February 2013, version 14.0.6134.5000 Test result: -issue still present
  • Installed CU April 2013, version 14.0.6137.5000 Test result: –issue not present (solved with this CU)

Conclusion

This issue is introduced with SharePoint CU April 2012 and resolved with SharePoint CU April 2013.

The problem is present only with documents originally created as doc files that contain hyperlinks to network shared folders and are converted to docx before uploading to a SharePoint document library.

Solution

Here are three different ways to fix this problem:

  1. Install the latest SharePoint cumulative updates or at least CU of April 2013. This is the best way to solve this problem for good.
  2. If for some reason you don’t want to update the farm and you have only few documents with this problem you can open the problematic documents with Word 2007 or newer, remove the hyperlinks to network shares and re-add them back (of course not with copy-paste but manually choosing on the Ribbon Insert->Hyperlink).
  3. Convert the problematic docx files back to doc files if that’s acceptable for you. With doc file you will loose all the functionality that docx files offer so you should better consider option 1 and 2 first.

“This file cannot be saved because some properties are missing or invalid”

Error


This file cannot be saved because some properties are missing or invalid.
Use the Document Information Panel to provide the correct property values. Errors for required properties are marked with a red asterisk, and errors for invalid properties are marked with a red dashed border.

Only specific pattern allowed. Only data in the following pattern is allowed: ‘.*\S.*’

Case

There is a document library in SharePoint 2010 site. Users are using Office 2010 32-bit.Saving an open document from client computers doesn’t work for all the client PCs. On some PCs saving the document fails and this error is shown: “This file cannot be saved because some properties are missing or invalid. Use the Document Information Panel to provide the correct property values. Errors for required properties are marked with a red asterisk, and errors for invalid properties are marked with a red dashed border”.
In the Document Information Panel there are no properties marked with red and everything looks fine.

Investigation

There are two cases I discovered that experience this problem and both are caused from the same bug in Office.

Case 1:

Labels are enabled for the content type in the document library and the label specified contains line breaks, for example {Field1}\n{Field2}.
The error occurs even without inserting the label in the document’s content. After removing the line breaks from the label the documents can be saved.

Case 2:

There were some hidden columns in the document library’s content type. I made them Optional and opened a document from a PC that is having the problem. In the Document Information Panel there was one property marked with a red dashed border.

This file cannot be saved because some properties are missing or invalid.

Right clicking and selecting “Full error description…” popped-up the following message: “Only specific pattern allowed. Only data in the following pattern is allowed: ‘.*\S.*’”.

“Only specific pattern allowed.

It turns out that the validation is not allowing line breaks in the property. After removing the line breaks I was able to save the document.

The question now is why the problem was present only on some of the PCs. Checking the Office build version discovered that the problem was present only on client PCs with Office 2010 14.0.7106.5003. Client PCs with Office 2010 without service packs (14.0.476.1000) are not having this problem. This is a bug introduced with Office 2010 updates. Microsoft is aware of this bug and they are working on it and will be fixed with the next Office 2010 updates. It’s been few months since then (October 2013) and the issue is still present. Hopefully they will release the hotfix soon.

Solution

(Bug fixed. Check UPDATE 24/03/2014 at the end of this post.)

Because this is a bug in Office 2010, as a temporary “solution” I uninstalled Office 2010 14.0.7106.5003 and installed a clean Office 2010 14.0.476.1000 without service packs. I’ll stick with 14.0.476.1000 until Microsoft fixes this bug. Hopefully it won’t take too long until they release the hotfix.

UPDATE 22/01/2014:
To find out which update is the problem I performed the following:

-Installed clean Office 2010 (32 bit) 14.0.476.100 – The issue is not present

-Then Installed Service Pack 2 14.0.7015.1000 –The issue is not present

-Then installed the updates after SP2 one by one until the problem started.

Discovered that KB2826026 (08/10/2013) is the update that has introduced this bug.

-To make sure that this is the only problematic update I uninstalled KB2826026 and installed the other latest updates (except KB2826026) and the issue is not present.

Microsoft hasn’t released the fix for this bug yet. Uninstalling KB2826026 solves the problem temporarily until the hotfix is released.

UPDATE 25/02/2014:
“The KB2826026 has been replaced by the KB2837583 (released 11/02/2014) but Microsoft did not remove the bug brought by the first KB. So you have to uninstall the KB2837583 otherwise you will have this bug again …” – visitor’s comment (Nicolas).

In my case uninstalling KB2826026 (now KB2837583) fixed the problem. If in your case that doesn’t solve the problem then try by uninstalling other updates released after September 2013. Check the comments below.

UPDATE 12/03/2014:

KB2837583 (released 11/02/2014) is now replaced with KB2878225(release 11/03/2014) but the bug is still not fixed. So this update (KB2878225) must be uninstalled too.

UPDATE 24/03/2014:

Good news! The bug is fixed with hotfix KB2878228. You have to download and install it manually because its not included with the automatic updates.

Change the URL of a SharePoint list or library

Below are listed three different ways to change the URL of an existing list or library.

1. With PowerShell

Changing the URL is possible by moving the root folder to a new URL. Here is a PowerShell script to change the URL of an existing library:

Add-PSSnapin Microsoft.SharePoint.PowerShell –erroraction SilentlyContinue

$libOriginalUrl = "/Lists/YourLibName1";
$libNewUrl = "/YourLibName2";
$web = Get-SPWeb -Identity http://....

$lib = $web.GetList($web.Url + $libOriginalUrl)
$rootFolder = $lib.RootFolder;
$rootFolder.MoveTo($web.Url + $libNewUrl)

2. With SharePoint Designer

Open the site in SharePoint Designer and in All Files in Site Objects right click the list and click “Rename” to rename it or drag and drop to move it to another folder. For example a list can be moved outside “/Lists” and the Url will change from “webUrl/Lists/List1” to “webUrl/List1”.
All Files in SharePoint Designer

3. With Windows Explorer

Its the same thing as with SharePoint Designer done in Windows Explorer without opening SharePoint Designer. To get to all files and folders of the site open a document library with Windows Explorer by clicking “Open in Explorer” in the Ribbon. Then in Windows Explorer move up in the folders hierarchy to show all the files and folders in the root of the site. You can rename a list/library and you can drag and drop the list’s root folder to add/remove parts of the Url as in the example with SharePoint Designer above. Because standard lists don’t have the option in the Ribbon “Open in Explorer” you can use any document library just to get to the folders of the site as explained in the previous paragraph and then find your list and rename/move it.
Site files in Explorer

Note:

Hyperlinks in Quick Launch will continue to point to the old URL of the list so after changing the URL you need to update the quick launch to reflect the new list name and URL.

Effects of temporarily disabling versioning for a SharePoint document library

Suppose we have a document library that has major and minor versioning enabled. We want to know what happens if we disable versioning and re-enable it again, and what is lost/retained from the items versions history.

Case:

There is a document library with major and minor versioning enabled, requires check out for editing document and there are workflows associated with the content types. We’ll observe what happens with the version history when the versioning is disabled and re-enabled. When the versioning is disabled the document library contains number of documents in minor and major versions, with version history, some document are in checked out state and there are document with workflows in process.

Test Results

After re-enabled the versioning the version history of the documents is preserved but any change done while the versioning was disabled has increased the major version of the document (document is published).

Example: Before disabling the versioning for the document library one document is in version 0,2 with version history 0.1, 0.2. After the versioning is disabled the item is modified. After re-enabling the versioning the change done while the versioning was disabled has increased the major version of the document (document published), so the versioning history now is 0.1, 0.2, 1.0 instead of 0.1, 0.2, 0.3 how would have been if the versioning was not disabled when the change has happened.

Every document that was not modified while the versioning was disabled has the full version history back and unaffected from the disable-enable versioning process.

Conclusion

If minor versions are enabled for a document library then temporarily disabling versioning will affect the version history if changes are made while the versioning is disabled. The problem is that every change in that period will publish the document to the next major version.

%d bloggers like this: