Document Set Shared Columns behavior - sub content types edit properties allow you to edit them?



    I am finding discrepancies with this  behavior between the service packs and cumulative updates for SharePoint 2010 Enterprise.

    In the content type hub, you have defined a custom content type derived off document set called docset1. It has a custom field based off managed metadata called sharedcol1. You set the docset1 to use this column as a shared column. The document set has a content type defined called doc1 which has custom column defined col1 which points to managed metadata.

    Next if you associate docset1 to a library and create a new document based off this document set called docset1example and file out sharedcol1 value, this works.  If you add a new document to this doc set based off the doc1 content type this also works and shares the column sharedcol1.

    The behavior that is inconsistent:

    If you edit properties of the new document, it allows you to edit the sharecol1 value. It doesn’t stick meaning it allows you to change the value from the docset sharedcolumn, but it doesn’t save.

    This behavior seems inconsistent between the updates to SharePoint. The above is the behavior fully updated with August CU. Earlier versions did not allow you to see or edit shared columns on sub content types that share these columns. I would expect that this would/should be the functionality?

    Can you please confirm how this is supposed to function?

    Friday, March 02, 2012 10:24 PM

All replies

  • Hello Samuel,

    Thank you for your question.

    I am trying to involve someone familiar with this topic to further look at this issue.

    Wayne Fan

    TechNet Community Support

    Monday, March 05, 2012 9:46 AM
  • Hi

    When you add a field on Document set to child content type as shared field that field gets added to child content type with attribute 'ShowInDisplayForm"="true" which makes it show in display form but not in edit forms. There is a timer job to sync the values of shared field between the document set and child content type.

    Are you sharing a column/field which is already there on child content type? if you don't really need it there and that might be causing the confusion.


    Yogesh Pawar

    Monday, March 05, 2012 11:47 AM
  • The column is not on the child content type.

    The problem is that on the edit forms, the shared field is displayed and is allowing for edits.

    Monday, March 05, 2012 3:11 PM
  • Any luck finding someone that has knowledge of this feature set and how it should be working

    Tuesday, March 13, 2012 6:10 PM
  • Sam:

    I can confirm this behavior on a new install of SP Server 2010 Standard with SP1 and the October 2011 CU. Document Set shared columns *do* appear when editing the properties of included documents.

    This is undesirable behavior which causes user confusion.


    Friday, March 16, 2012 8:59 PM
  • Hey Samuel,

    I am in the process of setting up a test environment so I can test your issue against the different CUs available. I will let you know as soon as I have done the testing.


    ScottC - Microsoft SharePoint Support

    Tuesday, March 27, 2012 6:23 PM
  • Hey Scott,

    Any progress in investigating this problem with shared columns in document sets? Any idea how to solve it? Any work around?

    Thanks for your feedback.

    Friday, April 06, 2012 7:55 AM
  • I am working to investigate this still. I will have more information next week.


    ScottC - Microsoft SharePoint Support

    Thursday, April 12, 2012 8:48 PM
  • I also have a Microsoft Support Case open. Accoring to the support tech I am working with, the product team has introduced this behavior as a new "feature" in SP1, August CU.  I filled out a Business Case and submitted why I feel this is a bug and how it is affecting our customers.

    After installing SP1, August CU:

    - Content Types created pre SP1, August CU will not expose shared columns in edit properties window.

    - Content Types created post SP1, August CU will expose shared columns in edit properties winodw.

    This makes no sense to me or our customers. If they were to change the behavior then SharePoint should work consistently with pre- and post- updates.

    Thursday, April 12, 2012 8:59 PM
  • Samuel,

    If you have opened a support ticket regarding this issue with Microsoft, then I would recommend pursuing a solution through that channel. I hope that you get your issue resolved to your satisfaction.

    ScottC - Microsoft SharePoint Support

    Monday, April 16, 2012 1:24 PM
  • Samuel,

    Any news from Microsoft regarding this issue? We have the same problem with some customers. It doesn't make sense at all....

    Tuesday, April 24, 2012 6:36 AM
  • Yes, I heard back. Unfortunately the SharePoint Product team does not consider this a bug and have no plans to fix.

    They provided me with a powershell command (which I altered) that corrects the issue. The downside of this is that the product team is going forward with the current deployment, and everytime a document set column or sub content type is modified the script needs to be manually reran.

    For now I have scheduled the script to run on a weekly basis.

    Monday, April 30, 2012 8:22 PM
  • Hello,

    I have the same issue.

    Can you, please, explain us what the script is doing to correct the problem, or share the script code. 



    Thursday, July 12, 2012 9:35 AM