In our quest to handle some requirements to levelize the type of data users are adding to Sharepoint, we have come up with the idea that we need to add a choice field to all existing content types to categorize each item/document/discussion as to the level of data it contains at the item level. This should ensure that when a user creates a new custom list or new task etc this field will be required at first but could be turned off if needed. I was hoping that this could be done using a feature but a I am unable to determine what approach to take. Can the field be created programmatically and then somehow be added to all the content types or even the base content type. It seems that if you can add it to the 0x base content type it should work. Can this be done?
1 Answer
Why not create the field declaratively using a feature and then use the OM to add the field to your base content type? This is the approach I use often and it works fine.
Without having any code in front of me the general approach (this doesn't even rate as pseudo code!) would be:
- Create a feature to deploy the custom field
- On the feature activation you can run all your code to manipulate the base content type. I prefer not to manipulate system content types but that's just me and in your case I think you will need to.
- Get the base content type (0x) and custom field in question from the root SPWeb
- Add the field to the content type and update it. Remember to push the changes to all inheriting content types (everything in your case) by including the true flag when calling update.
The updated MSDN documentation on SPContentType has a good example of adding a field to a content type which is pretty similar to the code you will need. I think the code hasn't changed from 2007/WSS to 2010.
A couple of other questions...
- How many site collections will you need to do this to? You will need to activate this feature on every site collection that requires this functionality.
- You could consider building a feature stapler for your custom feature (assuming you use one) if you need to ensure all future sites will include this custom field/content type association.
-
This needs to apply to every site collection and all future site collections. I could use a feature stapler, but I am not sure how I could apply that in this case. I was hoping that this could be done on the entire farm, but I realize that your solution is the best and possibly only approach. Jul 2, 2010 at 22:09
-
Unfortunately feature staplers are not retrospective to existing sites as far as I know :( A quick powershell/command-line script to activate the feature on existing sites will get you to a 'consistent' state. I usually combine STSADM enumsites with some copy/paste to make a quick batch script for this sort of thing... Jul 3, 2010 at 0:05
-
Unfortunately this is all running on server 2003 wss 3 so I do not think that powershell would help much right? If we do not have a lot of existing sites yet then manual addition to those would have to do, but this would work on future sites right? Jul 3, 2010 at 1:10
-
You can install powershell on W2003 & WSS if your really keen for powershell. There is even a whole lot of community commandlets too. In this case there is nothing wrong with a quick command-line app to do the job! For a small number of sites then manual activation is probably a better use of your time. Yes the feature stapler will set you up for the future sites. Jul 3, 2010 at 3:17
-
I am still having a hard time with this. I have a feature and it deploys fine and creates the field. I just can not seem to get a handle to the site in code on the activated event. I am stapling the feature inside the onet.xml of a site template. When deploying the template I want this feature to activate which it does, but it always errors when I try to get a handle to the site or web. Jul 6, 2010 at 12:55