I am seeing some strange behavior with Document Sets when I have more than one custom Document Set content type in the same document library. Basically what is happening is that when I go to view (or edit) properties for a document contained in a Document Set of Type A, I see the shared fields from Document Set Type A and Document Set Type B. Now, only the values of the actual containing Document Set are pushed down, but the fields from the other type are there (and are empty).
This presents a problem because:
a) it's confusing to see.
b) there are also document specific fields (not shared from the Doc Set, but on the document itself) which may need to be edited. However, it's receiving empty shared fields from the other Doc Set content type, some of which are required fields, which then prevents successful editing and saving of the document properties.
Has anyone else run into this problem? Could it have to do with the way the content types were created and deployed? Or does it just have to do with how shared fields are treated at the list level?
The custom doc set content types were defined in VS and deployed through a feature to a content type hub. They were then published to propagate them out to the sites that are actually using them. Then, after they exist on the sites through syndication, a feature is activated on the consuming sites that has list instance definitions that explicitly include the content types that are supposed to be in those specific document libraries. Does this method of getting the custom content types in to the document libraries where they are supposed to be bypass some code or settings that would prevent this sharing of fields between content types?
Any insight or speculation would be appreciated...
