Freigeben über

SharePoint 2013 Custom List displaying duplicate(?) modification entries

  • Artikel

This article was written to help explain the behavior seen by some when the "perfect storm" occurs in their SharePoint Custom List or Document Library. What do I mean by the "perfect storm"? In this scenario I'm referring to what occurs when a SharePoint site admin applies the following settings/configuration to either a Custom List site or to a Document Library. If you've experienced this scenario in your own environment or have had to help someone resolve this then you know how difficult it is to even explain when this happens. So I'm going to do my best to outline a real world scenario where this occurred, why it occurred and how best to get around it.

As a SharePoint Site administrator you've been given the task of finding a solution for the following request:

You've been dubbed the resident SharePoint guru of Contoso University's literature department. Russell Johnson, one of the professors, has asked you to add a new sub site under the site https://ContosoUniversity.edu/Liter8r/101. Your job is to evaluate Professor Johnson's expectations from the site and provide a solution.

The professor and the rest of his team are planning to host a 'Short Stories' competition for their young authors. The students are expected to register on your new SharePoint site, upload a copy of their original short story and then each teacher will critique the students work and elect a winner.

After (not so much) deliberation you come up with the following sub site setting for Professor Johnson's upcoming competition:

  • First you decide to create a Custom List site under the https://cu/Liter8r/101 master site.
  • Second, you go to the new sites List Settings and you enable versioning on the site in order to keep track of any changes being made to the items throughout the competition. Just the minimum setting to allow a new version each time an item is edited.

 

  • Then, while you're in the list settings, you add a new column so that all new items added can have their own comments field. You set it up for multiple lines of text and since you have versioning enabled the option to append changes to existing text is available so you add that in there too.

 

  • Add each of the students from the Literature classes involved to the site permissions so they may create their own Items.

  •  At this point you explain to the students and teachers involved with the competition how to use the site.

    • Student goes to the new SharePoint site and selects +New Item.
    • As part of the new item creation process the student gives it a name that includes the student name and the title of the short story then click OK to create.
    • The student can now click on their new item to open it up and add any comments to the new Multi Text column field that you added to the Custom List sites configuration.
    • From the tools ribbon at the top of the now open item the student can select to edit the item further or attach a file. In this case the student will select to attach a file and they will upload their short story in Word format to the item and click OK.

    As all students continue to follow these steps the professor and his team can open up the newly added items, open the attached Word document, read it and add their own annotations in edit mode. They can choose to add a comment to the item and move on to the next students listed item.

    Make sense so far? Does it sound like a good solution for this projects requirements? Well this is what actually happens…..

            Users, both student and teacher in this case, will observe what appears to be duplicate entries in all these items. Trouble is that they aren't duplicates. This behavior is actually by design. It's a normal behavior when both the versioning and append features fulfill their designed roles. When a custom column with the append option is added to the site design any data that is placed into this column will populate BOTH the items field itself as well as one of the metadata fields of the attached document.

            Since appending is not tracked like versioning is it will maintain whatever data is in its comment field until it is manually changed during an edit of the item or otherwise removed. So each iteration within the items modification list will appear to be duplicating the comments added by the last user. In fact it is just appending whatever the last update was to the comments field. Add to the confusion by editing the attachment and making changes or modifications of any kind and you'll see what appears to be multiple duplicates. Why? Because the item having been opened for editing now places a new modification entry in the list showing the users name, date and time of enabled edit (appending the latest comment to it…even if the comment was not made by the current user). It will then add another modification entry to the list of changes whenever the attachment (currently opened for editing) had modifications made to it and the attachment is saved. It doesn't have to be closed at this point for the new modification entry to appear. As long as a change is made and the document is saved EITHER MANUALLY or with AUTOSAVE. So depending on how long the document is open for editing and changes are made and saves of an auto or manual nature are occuring you will see what would otherwise look like duplicate modification entries in the modifications list. Now that was a mouthful! See why I thought it was best to describe a scenario with a complete implementation of this configuration? Try explaining this in two sentences or less to a support engineer and expect to get assistance that actually addresses your problem.

            One other thing to take note of in order to debunk the idea that these are bugged duplicate entries is to look closely at the modification date/time stamps for each entry. If you are trying to test your theory you are likely running through these steps quickly to see if it duplicates. If so….then yes it will look like a duplicate because the time it took you to run through the steps was likely within a minute. If you go through each step slowly….even waiting a full sixty seconds between steps you will see that each entry in your modifications list is taking place at very different times. Thus….not duplicated….but behavior completely natural for the versioning and append features to display under these circumstances.

              So now what? How do I get around this behavior? In my experience you have a couple options. You can remove the append option from the custom column you created to hold comments. Now you won't get a quick and easy modifications list to reference by simply opening the Custom List item but you can open the item and select Version History from the tools ribbon. This way you can still maintain a list of any changes to the document, including comments, but without the appearance of duplicate entries because the comments will no longer be required as an appended item. You will get a list of strictly changed/modified occurrences, by who and at what date/time.

    The other option? You can basically use any of the multiple SharePoint templates that suit this process….just don't use versioning AND append to track changes.

    I hope this proves helpful to some of you out there struggling with this scenario and tricked into thinking it's a bug or that something in your configuration is "broken". It's not broken. Just not a great combination of functions.

Comments

  • Anonymous
    April 07, 2015
    Thanks for this helpful information I agree with all points you have given to us. I will follow all of them.