After wrapping up a project that used content types extensively, I decided to write a series of posts detailing the headaches encountered so far.

This is part 1.

Hidden Fields and Inherited Content Types

If you create a site content type through the UI and set a column to hidden, then create another site content type that inherits from the first one, and finally add that content type to a list, the column that was hidden will not be available anywhere in the UI on the list. Note that if you just use the base content type directly in the list, the hidden column WILL be visible in the list UI, and can be used in Views and toggled back to Optional or Required. 

Figure 1: Base Content Type

Figure 2: Child Content Type (notice hidden column is visible)

Figure 3: Child Content Type in List (notice missing column)It appears that Microsoft is assuming that a hidden column in a parent content type should not be able to be overridden once used in a grandchild content type. Whereas, some people might want to use the Hidden option to simply set a default for child content types, which may need to be overridden in particular lists or grandchildren.

The major pain with this is that you cannot regain the visibility of the column through the UI, even if you go back to the parent content type and set the column to Optional or Required. At that point, the column on the list is set to hidden, and has the CanToggleHidden attribute set to false. You have to either delete the content type from the list and re-add it (which will not work if you have list items already using that content type), or you have to resort to reflection to programmatically fix the column.

Ideally, content types created through the UI should have all of the granularity that is present in XML content type definitions. You should be able to specify ShowInEditForm, ShowInViewForm, CanToggleHidden, etc.