Freigeben über


Modified By Column does not get updated

Have you ever seen the following behavior ?

You create a new document library and start uploading content.Then the users start modifying the documents, however, the Modified by  field does not update to reflect the Name of the user that modified the document. Instead, the Name of the user that created ( or otherwise the first user that modified the document ) is displayed.

Why ?

The Explanation resides in the Modified by Field Definition as it is defined at the list Level.

An out of the box Editor field has the following SchemaXML (as , for example in https://msdn.microsoft.com/en-us/library/dd931513(v=office.12).aspx ):

 <Field ID="{d31655d1-1d5b-4511-95a1-7a09e9b75bf2}" ColName="tp_Editor" RowOrdinal="0" ReadOnly="TRUE" Type="User" List="UserInfo" Name="Editor" DisplayName="Modified By" SourceID="https://schemas.microsoft.com/sharepoint/v3" StaticName="Editor" FromBaseType="TRUE"/>

 if you retrieve the SchemaXML of your field through Powershell, you may notice the following differences:

  • you have Version="1" in the Definition
  • FromBaseType="TRUE" is missing

ex:

 <Field ID="{d31655d1-1d5b-4511-95a1-7a09e9b75bf2}" ColName="tp_Editor" RowOrdinal="0" ReadOnly="TRUE" Type="User" List="UserInfo" Name="Editor" DisplayName="Modified By" SourceID="https://schemas.microsoft.com/sharepoint/v3" StaticName="Editor" Version="1"/>

 This means:

  • the field is customized and it's definition was modified from OOB

If you do not have this differences STOP here and look for other potential reasons. If you do, read further.

 

You may ask : "yes, but I created a brand NEW document library and I have not customized anything, how come it is customized?"

The answer is simple: the field is customized at the web level (or even higher, if you use content type hub and modified this at the hub level), which means, each document library will be created with the "modified" field.

How to solve this (do not ask how repair the actual value of the field so that it reflects the last modified user, that would be a scripting exercise to retrieve the Name of the user from the actual document properties, then set the value of the Editor Field at the SPListItemLevel to that value)

To revert the functionality and make the field "behave" :) you need to :

  • repair the field's SchemaXml at the Web level (so that the future document libraries do not get created with the wrong field)
  • repair the field's SchemaXml at the Doclib level

now on to scripting ( if you use a Content Type hub, you need to go at the hub level and fix the definition at the source, then propagate the field downwards):

BE ADVISED THAT MANUAL MANIPULATION OF SCHEMA XML CAN BREAK THE ELEMENT. DO NOT PROCEED UNLESS YOU HAVE WORKING BACKUPS.

At the web level

$w = get-spweb https://urlof the affected web

$f = $w.Fields.GetFieldByInternalName("Editor")

$fieldSchema=[xml]($f.SchemaXml)

if($fieldSchema.Field.Attributes["FromBaseType"] -eq $null)

{

$frombasetype=$fieldschema.CreateAttribute("FromBaseType")

$frombasetype.Value="TRUE"

$fieldSchema.Field.Attributes.Append($frombasetype)

}

$fieldSchema.Field

if((Read-Host "Are you sure? (y/n)").ToLowerInvariant().StartsWith('y'))

{

$f.SchemaXml=$fieldSchema.InnerXml

$f.update()

}

 

At the List level :

$w = get-spweb https://urlof the affected web

$l = $w.Lists["myBrokenList"]

$f = $l.Fields.GetFieldByInternalName("Editor")

$fieldSchema=[xml]($f.SchemaXml)

if($fieldSchema.Field.Attributes["FromBaseType"] -eq $null)

{

$frombasetype=$fieldschema.CreateAttribute("FromBaseType")

$frombasetype.Value="TRUE"

$fieldSchema.Field.Attributes.Append($frombasetype)

}

else

{

write-host "field at " $w.Url " List " $l.Title " is ok " $fieldSchema.Field

}

$fieldSchema.Field

if((Read-Host "Are you sure? (y/n)").ToLowerInvariant().StartsWith('y'))

{

$f.SchemaXml=$fieldSchema.InnerXml

$f.Update()

$l.Update()

}

}

 

The Field Version will increase but this should not bring any problems. If you want to script this over all the lists, encompas the code above in a foreach block.

And, of course , although the operation is pretty trivial, straightforward and reversible through the same procedure, safety first, ALWAYS make sure you have working backups :)

 

Cheers.

Comments

  • Anonymous
    May 17, 2013
    The comment has been removed
  • Anonymous
    August 04, 2015
    The script is now using XML so the potential space issues should not appear , but thanks for pointing this out.
  • Anonymous
    July 15, 2016
    Hi, Great post and has fixed the list level issues that we had in our site collection which is great. However, I am still having an issue with new doc libraries having the same issue. So I attempted to run the web level fix on our SP2010 farm from your article but got the error below. I would be grateful if you can give me any guidance. Thanks, MarkUnable to index into an object of type System.Xml.XmlAttributeCollection.At D:\Get-ModifiedByIssue-UpdateWebApp.ps1:4 char:34+ if($fieldSchema.Field.Attributes[ <<<< "FromBaseType"] -eq $null) + CategoryInfo : InvalidOperation: (FromBaseType:String) [], RuntimeException + FullyQualifiedErrorId : CannotIndex