06/10/2009

SharePoint Tips: Content Type Visibility on NewMenu

I've built a solution with a few custom ContentTypes in a list definition. Now, removing these from the NewMenu has to be easy right? Just add a HideCustomAction definition to your instance file. Not so easy to find the ID's that will be used for those content types is it? Well, here is a solution that will remove the ContentTypes from the NewMenu but allow them to hang around for use in defining whatever it is your heart desires.

To specify visibility on the Microsoft.SharePoint.StandardMenu.NewMenu in a document library, try changing the RequiredClientRenderingOnNew option to false, and update the content type definition as below:

The correct solution for document libraries is the following:

SPWeb web = SPContext.Current.Site.RootWeb;
web.AllowUnsafeUpdates = true;// if done on get
SPList list = web.Lists["LIST NAME LIST NAME PUT LIST NAME OR GUID HERE"];

foreach (SPContentType ct in list.ContentTypes)
{
if (ct.Name == "Content Type Name")
{
ct.Hidden = true;
ct.RequireClientRenderingOnNew = false;
ct.Update();
}
}
web.AllowUnsafeUpdates = false;// if done on get

I'm doing this in a feature receiver and it works by design. If done in AllItems.aspx (or any GET request it seems) you need to refresh the page twice for this to work by design (one refresh appears to set the value in content type but this is done after it's read into the display).

The other thing I've got in that habit of doing is force deleting lists when I make changes. I'm not sure how "required" this is but in order to get stability in my test results this seems to make a difference.

Here is how I was force deleting the offending lists:

stsadm -o forcedeletelist -url http://SERVERNAME:PORT/Lists/LISTNAMELISTURLNAMELISTURLNAME


Wish SharePoint would work as advertised ... sigh ...

No comments: