Second Life of a Hungarian SharePoint Geek

October 10, 2009

Changing system properties for an item from the SharePoint user interface – part 1

Filed under: Custom fields, SharePoint — Tags: , — Peter Holpar @ 03:43

UPDATE: See the source code of this post on CodePlex.

A few month ago I had a thread at MSDN SharePoint – Development and Programming forum about changing file creation dates in SharePoint.

You might know that there are tools that make it possible to change system properties of files in file system. You can read more about it here:
How to change the last modified date, creation date, and last accessed date for files and folders

There is a nice tip in Steven Van de Craen’s Blog about how one can change these properties from code in SharePoint:
SharePoint 2007: Update system properties (Created, Created By, Modified, Modified By)

I’ve decided to implement a solution that has some kind of user interface and makes it user friendly to manipulate this properties. It would have several advantage to be able to set these values (just joking, don’t take me too serious):
– No boss, it was not me, who uploaded the report that contains invalid numbers to the site.
– Yes boss, the document was uploaded by the deadline, probably you checked that wrong yesterday.

My first idea was a WinForms application but it would have a few drawbacks:
– Require me to create the WinForms application, design user interface.
– I have to implement the listing and selecting the SharePoint items for which I want to set the properties.
– As I do not know how to set these properties remotely, it will be limited to be run only on the server, or I would have to wrap the functionality in a custom web service.

So I’ve changed my mind, and decided to implement the tool as a server side solution. As the lists and items are displayed out of the box on SharePoint web UI, it was the quickest to choose a way that extends these forms and that was developing a custom field.

After the solution is deployed to the server, a new field type can be selected when configuring your list settings and choosing Create Column:


As we will see it soon, this field should not be added to the list views:


A typical screenshot of the field when an admin user is logged in:


The same field for a non-admin user is rendered like that:


Currently there is no download provided for this post, but I plan to publish this solution on CodePlex later either individually or as part of an existing package. Until that if you would like to use the code, feel free to copy that from this page, but don’t forget to change the public key token to match the one in your project, deploy the assembly into GAC, and add the control as SafeControl in the web.config of your site.

It is important to note, that the solution is provided “AS IS”, meaning not fully tested, data loss or side effects might be possible, and no support is guaranteed, etc. By using the code above you explicitly agree with this conditions. It might be also dangerous for your business to include this control on your site and allow users to change system properties. Just mention that for you to not say later I have not forewarned you about that.

My solution derives from a simple Text field, but it really has not much importance, as this field does not store any values, it is just a dummy field to inject user interface element for list items.

The XML schema for the field (fldtypesCorrector.xml, located by default at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML) contains nothing special. The field is not intended to be included in a view, but if it is added to one, the we display simply “Use the edit form” caption for each list items.

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <FieldTypes>

   3:   <FieldType>

   4:     <Field Name="TypeName">CorrectorField</Field>

   5:     <Field Name="ParentType">Text</Field>

   6:     <Field Name="TypeDisplayName">Corrector field</Field>

   7:     <Field Name="TypeShortDescription">System properties editor</Field>

   8:     <Field Name="UserCreatable">TRUE</Field>

   9:     <Field Name="ShowOnListAuthoringPages">TRUE</Field>

  10:     <Field Name="ShowOnSurveyAuthoringPages">TRUE</Field>

  11:     <Field Name="ShowOnDocumentLibraryAuthoringPages">TRUE</Field>

  12:     <Field Name="ShowOnColumnTemplateAuthoringPages">TRUE</Field>

  13:     <Field Name="FieldTypeClass">Grepton.SharePoint.FieldTypes.SPFieldCorrector,CorrectorField,Version=,Culture=neutral,PublicKeyToken=062a83cb41c3b1cb</Field>


  15:     <PropertySchema>

  16:         <Fields></Fields>

  17:     </PropertySchema>


  19:     <RenderPattern Name="DisplayPattern">

  20:         <HTML>Use the edit form</HTML>

  21:     </RenderPattern>


  23:   </FieldType>

  24: </FieldTypes>

It is displayed on the figure below:
The rendering template for the field (CorrectorField.ascx) is also not too exciting. It contains only a DateTimeControl for both created and modified dates, and a PeopleEditor control for both created by and modified by. This file is located by default in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES folder.
   1: <%@ Control Language="C#" Debug="true"  %>

   2: <%@Assembly Name="Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

   3: <%@Register TagPrefix="SharePoint" Assembly="Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" namespace="Microsoft.SharePoint.WebControls"%>


   5: <SharePoint:RenderingTemplate ID="CorrectorField" runat="server">

   6:     <Template>

   7:         Created:<br>

   8:         <SharePoint:DateTimeControl ID="CreatedDate" runat="server"/><br>    

   9:         Modified:<br>

  10:         <SharePoint:DateTimeControl ID="ModifiedDate" runat="server"/><br>    

  11:         Created by:<br>

  12:         <SharePoint:PeopleEditor ID="CreatedBy" MaximumEntities="1" MaximumHeight="1" MultiSelect="false" SelectionSet="User" runat="server" ValidatorEnabled="true" />

  13:         Modified by:<br>

  14:         <SharePoint:PeopleEditor ID="ModifiedBy" MaximumEntities="1" MaximumHeight="1" MultiSelect="false" SelectionSet="User" runat="server" ValidatorEnabled="true"    />

  15:     </Template>

  16: </SharePoint:RenderingTemplate>

The information I’ve found on Karine Bosch’s blog about the controls mentioned above was a great help.
Since we do nothing special (do not store or validate values) in our field, its class is rather simple too.
   1: using System;

   2: using System.IO;

   3: using System.Security.Permissions;

   4: using System.Text;

   5: using System.Text.RegularExpressions;

   6: using System.Xml;

   7: using System.Web;

   8: using System.Web.UI;

   9: using System.Web.UI.WebControls;

  10: using System.Web.UI.HtmlControls;

  11: using Microsoft.SharePoint;

  12: using Microsoft.SharePoint.WebControls;

  13: using System.ComponentModel;

  14: using System.Diagnostics;


  16: namespace Grepton.SharePoint.FieldTypes

  17: {


  19:     //Field inherits from the WSS base type SPFieldText

  20:     public class SPFieldCorrector : SPFieldText

  21:     {

  22:         public SPFieldCorrector(SPFieldCollection fields, string fieldName)

  23:             : base(fields, fieldName)

  24:         {

  25:         }


  27:         public SPFieldCorrector(SPFieldCollection fields, string typeName, string displayName)

  28:             : base(fields, typeName, displayName)

  29:         {

  30:         }


  32:         //Returns a field control for the page

  33:         public override BaseFieldControl FieldRenderingControl

  34:         {

  35:             get

  36:             {

  37:                 BaseFieldControl fldControl = new CorrectorFieldControl();

  38:                 fldControl.FieldName = InternalName;

  39:                 return fldControl;

  40:             }

  41:         }


  43:         //Returns the field value object

  44:         public override object GetFieldValue(string value)

  45:         {

  46:             return null;

  47:         }


  49:         //Performs all validation before the field is stored

  50:         public override string GetValidatedString(object value)

  51:         {

  52:             return String.Empty;

  53:         }


  55:     }


  57: }

In the next part of this blog entry you can read more about the implementation of the custom field.

1 Comment »

  1. […] weblog « Deleting documents or folders using the built-in web services Changing system properties for an item from the SharePoint user interface – part 1 […]

    Pingback by Changing system properties for an item from the SharePoint user interface – part 2 « Second Life of a Hungarian SharePoint Geek — November 21, 2009 @ 03:46

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: