This is sort of relevant to an earlier post on the Document Information Panel, and showing fields in it.
The behaviour depends on if you’ve enabled ‘Allow management of content types’ on the Document Library Settings > Advanced Settings page.
If you’ve not allowed management of content types, well, you just add the column and it’ll appear in the document information panel. That’s great! The new column will not show as belonging to any content types, as the ‘Test‘ column is in the screenshot below:
However, if you have allowed management of content types for the library, things get a little more complicated. When you add a new column, in the ‘Additional Column Settings’, there will be an option for ‘Add to all content types’. If you check this, well, it’ll add that column to all the content types currently on that list. This will make it appear on the document information panel. This is what I did with the ‘Test2′ column above (but before I added the Picture content type to the library).
(As a side note, the content types on the list are actually ‘children’ of your Site content type rather than instances of it. This means that if you update the content type on that list, it won’t update the parent content type, or other lists that use that content type. Similarly, it mean that if you update the parent content type – say, you edit the site content type – you need to update child content types with those changes to affect lists that are using them already. But that really should be another post, sometime.)
If you don’t check that ‘Add to all content types’ option, well, it doesn’t add it to the document information panel. Finally, what if you have added a column all content types, and you add a new content type to the list? Well, your new content type will not have that new column applied to it – and the only way I can see of applying it to the new content type is actually to delete and recreate it. Of course, that means deleting a column that contains data, so that is less than ideal. This is what happened with the Picture content type – I added it afterwards, and you can see that it doesn’t use the ‘Test2‘ content type.
For that reason, be very careful when adding columns to library that is allowing management of content types. If possible, keep the columns in the Site Content Type (i.e. the parent).
Andy Burns' Blog 
[…] Related to this, then, is the question of what happen if you add a column to a list. However, I’ll cover this in another post. […]
I am new to SharePoint. This article is a great help for me. But I still have problems with columns and content type.
I am playing with the Pages library under a publishing site. I add one site content type (which is inherited from the top level site) to the library. As a result it add columns that are referenced in the content type into the Pages library.
As I understand all these columns become local to the library. And the content type becomes a list content type which is local to the library too.
However I can not remove any column from the list content type. I can only
change some settings of this colume such as “This column is required or optional or hidden”. or change the name of this column.
If both the content type and the column become local to the library/list, why cann’t I modify the list content type to remove one column? Why I can not delete the conlumn even if no other list is using it?
Kevin
The reason you can’t do that is that your List Content type has it’s columns defined by the Site Content type. It’s not so much that Site content types ‘become local’ (i.e. become List Content types) as a child content type is defined and used on the list.
Child content types MUST have the columns as their parent has – so in this case, the List Content Type must have those columns as defined in the Site Content Type. A child content type CAN have extra columns, but as a minimum it MUST have the same columns as the parent. Hence, you can’t delete those columns.
It is an ‘inheritance’ system, not a ‘copy’.
That would be my guess, but without seeing your system, it’s kind of hard to tell.
Thanks. Now I understand better. However in my case:
There are two content types “Article Page” and “Welcome Page”. Both are defined at top level site. The “Article page” has an column “Article Date” while the “Welcome Page” does not have this column.
I add these two content types into the “Page” library under a subsite. “Article Date” becomes a column of the “Page” library.
Under the page library settings, I accidentally add “Article Date” column to the “Welcome Page” content type by using “Add from existing site or list columns” function. After this I can not remove “Article Date” from the “Welcome Page” ccontent type.
On the “List Content Type: Welcome Page”, I can click on the “Parent: Welcome Page” link. But in the parent, there is no “Article Date” column.
It is obvious to me that the list content type “Welcome Page” does not get the “Article Date” column form its parent. The only reason I can think of is that the “Article Date” column is not defined at the library. So it can not be remove from any content types in the library!?
Kevin
Hmm. Okay, I’ll give that a try tomorrow lunchtime and let you know if I get the same result. It would seem to be a bit of a bug if that’s the case.
Hi Andy,
Have you had a chance to look into this problem?
Thanks
Yes, I took a look over the weekend. Nope, I had no problems. I couldn’t reproduce your problem. I could always remove a column. I created two sibling content types as you’ve described, added the same column to each of them, actually used the content type – and it’ll still let me delete the column of either content type, independently.
The only way that I could get a similar thing was through the use of a parent content type containing my new columns, but you say that this isn’t what you’ve done.
I am not sure if your test is the same. I tried on a different farm and got the same result.
Did you create the site content type on the site itself or on the top level site of the site collection?
It is true that if the content type is defined at the site itself, there is no problem. But my situation is that the content type is defined at top level and it is the subsites that are having this strange behavor.
Also, does the publising site make a difference?
Thanks
I have the same problem.
When you add “article date” to a list with content types, you can not delete the column. I made it hidden so the users won’t see it.
[…] content types on a list are actually children of the site content types. I’ve also looked at adding columns to list content types, which naturally enough doesn’t affect their parent site content types. Anyway, there are […]
Just in regards to your comment “the only way I can see of applying it to the new content type is actually to delete and recreate it”: you can add existing columns to a content type that you added to the list by clicking on the content type name and then select “Add from existing site or list columns”. This does not only allow you to add columns from your pre-defined site columns, but it also allows you to add “existing list columns”, which are the columns you created manually on a list-by-list basis. So you can add those to a content type without having to delete them first.
You can add existing columns to a content type using the below block. No need to delete and recreate
$ct = $list.ContentTypes[“your content type name”]
$ct.ReadOnly = $false
$spDocIdField = $list.Fields[“Document ID”] #Ideally adding this field is enough to see the document id in view properites
$ct.FieldLinks.Add($spDocIdField)
$spDocIdField = $list.Fields[“Document ID Value”]
$ct.FieldLinks.Add($spDocIdField)
$spDocIdField = $list.Fields[“Persist ID”]
$ct.FieldLinks.Add($spDocIdField)
$ct.ReadOnly = $true
$ct.Update()