SharePoint Documents in "Checked Out" limbo mode after upload from explorer with mandatory fields not completed

We have been uploading documents into SharePoint from the file system by dragging and droping them from Explorer, and we could'nt work out why they were being shown as "Checked Out" even though the Version Control settings were set to not use "Check-in/Out".

The reason turns out to be related to mandatory fields being by passed by the Explorer upload method. If you load a document via the filing system and a mandatory field is not completed then Sharepoint leaves the document in a “Checked Out” state. However you cannot “Discard the Checked Out” state because no document has been “Checked In” in the first place !

So you have the situation where a document is in limbo – not checked in or checked out but only visible for the user who loaded the document to complete the mandatory fields.

BUT even if you do complete these fields – it would seem that Sharepoint keeps the document in the limbo state and won’t allow you to do anything with them unless you fully check them in.

AND the problem is that SharePoint doesn’t have a “bulk check-in” function!

Reference: Automatically checkin files after uploading « SharePoint, ASP.NET and more

Binding Excel 2007 values using (DIP) Server Document Properties to Sharepoint- Not Simple or Intuitive

We had a requirement to link values entered in Excel 2007 cells so that when they were saved to a Sharepoint Document library those values were seemlessly displayed Document library as fields.

This functionality is handled much more easily by Word 2007 - see these excellent articles (DIP Metadata and Word 2007 Custom Doc Properties) - but Excel 2007 doesnt seem to share this functionality out of the box.

It turns out that there are 3 types of Metadata Properties in Excel 2007 (where WB is the ThisWorkbook object in this example):

• WB.BuiltinDocumentProperties
• WB.CustomDocumentProperties
• WB.ContentTypeProperties

To access this Mata data visually use the Excel "Office button" -> Prepaire -> Properties menu. Choosing "advanced properties" gives you access to both add new custom properties and the built in properties. You can assign fixed text values to them or link them to named ranges within the sheet, however you cannot get to the Server Document Properties from this dialog.

ie the XL-> Custom Properties GUI only gives you access to the following Property sets (and of course these aren't what you need for Sharepoint)

• WB.BuiltinDocumentPropertiesSet
• WB.CustomDocumentPropertiesSet

To update the data which will feed back to Sharepoint fields you need to use code to get to the WB.ContentTypeProperties object which has a type of "MetaProperties".

The WB.ContentTypeProperties object is a collection which can be iterated through and each field has an ID and Name and a Value. The ID is an internal value and seems to Map to the same internal name as that of the Sharepoint field it is connected to.

{Note: the internal field names can lead to some confusion such as where a field with a Name of "col1" seems to create an internal ID name of "_x0063_ol1" and a field with a Name of "Project Lead Finance" has an internal ID name of "Project_x0020_Lead_x0020_Finance". This is normal Sharepoint practice!}

Using macro code to set the values of a MetaProperty in this way seems to trigger an event in the Server Document Properties DIP (Document information Panel) to update the field value to the new value you've set. {Note: The DIP is an InfoPath based piece of XML which displays fields in Office 2007 applications. It may be possible to code against it to achieve a more automated link to native Excel custom properties but I haven't had a chance to look at that yet}

Below is a very simple piece of code to set a Server Document Property to the value of cell A1:

Sub SetServerProperties()
Dim WB As Workbook
Set WB = ThisWorkbook
For Each Prop In WB.ContentTypeProperties
If Prop.Name = "Project Lead Finance" Then
Prop.Value = Range("A1").Value
End If
Next Prop
End Sub

Using macro code has the disadvantage of Excel documents having to be saved as XLSM documents and I am sure there must be a way to trap an update event of an standard Excel Custom property using something like VSTO, however that is for another post.

{Note: for Excel 2003 just updating the fields in WB.CustomDocumentPropertiesSet before a save does seem to pass them back to Sharepoint ok}

My thanks to an article published by Sadalit Van Buren who pointed me in the right direction with this article A Matter Of Degree: XML Mapping of Document Properties with Excel and SharePoint - Not Simple or Intuitive

Sharepoint Permission levels and permissions

Ive been working on setting Sharepoint permissions programmatically at a document level and found an interesting article below:

One of the things we noticed last week was that if you set the permissions on a single folder or document for someone who is not already in the document library, sharepoint adds them to the document library permissions root with [Limited Access].

The full article is here http://office.microsoft.com/en-us/sharepointtechnology/HA101001491033.aspx. , but in summary:

Limited Access


The Limited Access permission level is designed to be combined with fine-grained permissions to give users access to a specific list, document library, item, or document, without giving them access to the entire site. However, to access a list or library, for example, a user must have permission to open the parent Web site and read shared data such as the theme and navigation bars of the Web site. The Limited Access permission level cannot be customized or deleted.
Note You cannot assign this permission level to users or SharePoint groups. Instead, Windows SharePoint Services 3.0 automatically assigns this permission level to users and SharePoint groups when you grant them access to an object on your site that requires that they have access to a higher level object on which they do not have permissions. For example, if you grant users access to an item in a list and they do not have access to the list itself, Windows SharePoint Services 3.0 automatically grants them Limited Access on the list, and also the site, if needed.

Referencing Sharepoint Assemblies on x64bit Installs causes build errors for ASP.NET apps (in VS.NET 2008)

Debugging a WCF application on a 64 bit server using VS2008 gave me odd errors where sharepoint.security.dll could not be loaded - it turned out that you have to use the 32bit version of the microsoft.sharepoint.xxx.dll libraries - see the following article.

robgruen's WebLog : Referencing Sharepoint Assemblies on x64bit Installs causes build errors for ASP.NET apps (in VS.NET 2008):