ServerTemplate of a SharePoint Record Library

Leave a comment

For creating a SPDSiteDataQuery I needed the ServerTemplate of a SharePoint Record Library. Could not find a post about it, so here it is:

BaseType = 1
ServerTemplate = 1302


Give SharePoint Site Columns (Fields) a different display and technical name via the webinterface

Leave a comment

Probably for some people this is obvious, but I just found out yesterday and I thought I should share it.

When you create a site column (or Field) as an installable feature you can specify a ‘DisplayName’ (the name that will be used to show the column via the webinterface) and a ‘Name’ which will be the technical name of the Field.

The webinterface does not seem to give you this possibility, somehow it seems you can only enter the displayname on the “Create new site column” page. However in reality it is both the ‘DisplayName’ and the technical name (or ‘Name’) that you specify on the moment of creation. Now here is a way how you can use the webinterface to create a sitecolumn that has different Display and Technical name:

Start by creating a new site column and give it the TECHNICAL column name. In this case I use “prefix_” as a prefix:

The fieldname that is both the display and technical name

Now to check the internal column name (you can hover over the display name and in the url that appears the technical name of the column is shown):

Url with the technical name of the column

No go back to the “Site columns” settings page and edit the site column that you have just created. Change the name into the DisplayName that you want the column to have:

The displayname of the column

Save the column and hover over the site column again. The internal technical name still has the prefix, and only the DisplayName of the column has changed!

The technical name still has the prefix

Claims Based Authentication, Item Based Permissions & Managed Metadata Solution

1 Comment

For my latest project I really started combining some of the specific SharePoint 2010 features. One of those cool new features is Claims Based Authentication. There are already a lot of articles about creating your own claims provider for SharePoint like:


What I used for my project is ‘Claims Augmentation’ which means that for my authentication provider I still use AD accounts. These accounts however are enriched with user-specific claim information on the moment they log in on the SharePoint website. After that it is possible to base your security on the augmented claims.

Claims Augmentation

Claims Augmentation

In my project ‘Case management’ plays an important role. I have created a Document Library and in that document library Document Sets are created of which each represents a different case. The most important aspect of these cases is that they are all of a certain type. Some users should have only access to cases of type 1, some users should only have access to cases of type 2 and some users should have access to both type 1 and 2. You get the picture ; ).

View of the Document Library

View of the Document Library

My solution is to use Item based security combined with claims based authentication. In my solution the claims are based on all possible case types. So for every case-type, there is a corresponding claim. On the moment of Document Set creation I break the role inheritance of the item (which is the Document Set), delete all other role assignments and add the role assignment of the claim that corresponds with the case-type. After that only users who possess the same Case-type claim have access to the Document Set and the underlying documents.

Item based permissions for documentset 1001 (Dutch language pack...)

Item based permissions for documentset 1001 (Dutch language pack...)

Remains the problem where I keep my list with all possible case-types (which is of course the same list that produces the claims). I decided to use Taxonomy feature of the Managed Metadata service for that. So now both the Case-type taxonomy metadatacolumn of my Document Set and the custom claims provider gets their list of claims/case-types from the Managed Metadata Service.

Taxonomy termset for casetypes and claims

Taxonomy termset for casetypes and claims

The custom claims provide uses a sql server table to determine which user has which claims. This table is queried each time a user logs in on the SharePoint website. It has a very simple structure with only 2 columns: username and claim.

The complete solution looks like this:

Solution overview

Solution overview

Eventreceiver that triggers on unzipping a SharePoint 2010 DocumentSet after routing

Leave a comment

I needed to automatically convert documents that are added to a Records Library to PDF. The documents are part of a DocumentSet when they are submitted to the record centre. They are routed to their final destination and after that they are unpacked (unzipped). The moment they are unzipped I wanted to convert them, so I thought as a trigger I could use the ItemAdded event for each document that was unzipped.

The ItemAdded eventreciever triggers when the documentset is added to the Record Library by the content router (so far so good), but when the DocumentSet is unpacked (unzipped) the ItemAdded eventreceiver is not triggered at all. Instead, to my surprise, for each document that is unzipped the ItemUpdated event is triggered. Unexpected, but it does the job.

Set maximum upload filesize SharePoint WCF service

Leave a comment

When I changed a SharePoint asmx webservice to a WCF service I ran into the problem that out-of-the-box you can only upload files (as bytestreams) with a maximum filesize of about 18 KB (which is not a lot). After some searching on the internet I found that the WCF endpoint settings should not be set in web.config, but that there is a convenience class “SPWcfServiceSettings”.

I use the featureinstalled method of the feature eventreceiver of the SharePoint WCF service to set the servicesettings.

wcf settings

Settings for WCF service

Please note that even if the name of your service has capitals, like “DMSService.svc”, you still need to reference your service in all lower case: “dmsservice.svc”. If your service is hosted in a folder for example “DMSServices/DMSService.svc” you need to reference your service without the folder path: “dmsservice.svc”.

Update “Created by”, “Modified by”, “Author” and “Editor” fields

Leave a comment

Last month I was working on a project which used a webservice to upload files to a SharePoint document Library. The webservice had to run under a service account, so the “Created by”, “Modified by”, “Author” and “Editor” fields always had the same value (like “Administrator”). I wanted the fields to have the value of the person that actually loads up/edits the file.

I eventually used the method below where “userName” is the name of the user that the fields should be filled with, “item” is the actual item that has been created/uploaded and “isCreation” indicates if the item is created (true) or updated (false).

You need submit the userName in your request message and the userName has to be known in SharePoint.

Method example

Newer Entries