Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have a feature (Web scoped) with a content type which contains a field (Type="Choice").

Values were A, B and C.

I've created a list based on this content type and added some elements in it.

I then added the choices D, E and F and changed the version of the feature.

I updated the solution and performed an upgrade on the feature with $feature.Upgrade($false).

I can see the changes at the Web level (content type has changed, field has changed) but the one in the list instance NOT. When I add a new element to the existing list it only shows choices A, B and C. If I create new lists based on the content type they show the now A, B, C, D, E, F choices.

How can I propagate the change into the old list so that the field shows all choices (A, B, C, D, E, F) when creating new elements?

share|improve this question
add comment

1 Answer 1

up vote 6 down vote accepted

Looks like you're using default Update method of SPContentType when updating your content type in feature updating receiver.

To push changes to all inherited list content types, you should use another overload of the Update method, and pass true to it:

contentType.Update(true);

Description of the parameter from MSDN:

updateChildren

Type: System.Boolean

true to push the changes made to the content type down to content types that inherit from it; otherwise, false.

Also you can check out this rather descriptive post from Charles Chen on the topic:

Update:

In this particular situation, turned out, that you don't need to update the content type at all, since it hasn't been changed itself. The point is, that Content Types in SharePoint does not include fields definitions, they include only FieldRefs, i.e. links to existing fields.

So, if you change some properties in underlying site field, the content type keeps unchanged, and you need to update the field rather than the content type.

And with fields, the same situation with overload is in place: use SPField.Update(Boolean) overload and pass true to it to update the field and propagate the changes to all implementations of the field.

Description of the parameter from MSDN:

pushChangesToLists

Type: System.Boolean

true to propagate changes to lists that implement the field; otherwise, false.

share|improve this answer
    
Thanks for pointing this out to me (+1). Tried to do an Update on the content type but it didn't work (as a guide to others, you have to get your content type from ContentTypes not from AvailableContentTypes which is read only :D). But it worked when I tried this on the field: $my_web.Fields["my_field"].Update($true). When should contentType.Update() be used and when field.Update()? When should both be used? –  JohnDoDo Oct 27 '11 at 8:04
1  
Ah, got it! Quite obvious: if you have site field, and you make changes to the definition of this field - you should use field.Update(). contentType.Update() should be used then you remove/add field to the content type. So if you made changes to a site field, content type actually haven't changed itself, because you have only a field link to the field in it. –  Andrey Markeev Oct 27 '11 at 8:34
    
Yes, it makes sense, I understand now. Could you please incorporate this into your answer so others can find the information more easily? I'll then mark it as accepted. Thanks a lot! –  JohnDoDo Oct 27 '11 at 8:48
    
You're welcome! Feel free to ask any further questions :) And yes, I've updated the post as you recommended. –  Andrey Markeev Oct 27 '11 at 9:49
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.