Unghosted Content-Type Title overrides FieldRef DisplayName

New problem that cropped up today.  On a SharePoint 2010 site, the Base Title field was modified with the intention of making it not required on the contacts list.  Now this should have been done on the content type, or list level, but as is possible to do, the site column itself was modified.  (Note I’ll use FieldRef and SPFieldLink interchangeably in this post as I’m pretty sure the CAML schema and OM both refer to the same data)

Fallout:  the toot title column is now unghosted and what we’re seeing is that the Title attribute for the root column is now showing up for all inherited fields.  Even those with a different DisplayName in their FieldRef.  Most prominently is the Last Name column on Contact Lists.

We can modify the column on each list to display properly but as soon as a new list is created, its back to “Title”.

I dug in with powershell and the SPFieldLink still specifies that it should read “Last Name” in the DisplayName property.  If I look at the site collection content type it still lists the column as “Last Name”

The only thing I can think of is that the code that renders the List view is improperly just applying the un-ghosted column title if it finds one and ignores the other cases.  Whereas with a ghosted column, it will respect the FieldRef’s DisplayName.

I don’t have a solution yet, but I’m seeing if this occurs in MOSS as well.  Until then do not modify out of the box root site columns!

Edit: Confirmed similar behavior in MOSS/WSS 3.0

*Update
I ended up having to contact Microsoft premium support on this one, and given the nature of licensing, support models, etc I’m not sure if I can publish the fix. That said, they have a quick solution that involves some of the out of the box features so please, if you have this issue and a support contract with them, open a ticket.

2010 Calendars won’t print in IE7

So your SharePoint site is using the new v4 UI, everything looks slick and pretty.  But wait, you work in an environment where you have to support IE7 and your calendars won’t print properly.  Given the popularity of SharePoint, especially among all of the large companies and the public sector, it shouldn’t be surprising that not everyone can just upgrade IE just because the calendar is broken as suggested here:

http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/thread/1d2555fe-f0aa-467b-8d2b-6732b5da52a4/

I find myself in that very situation and I’m hoping that I can offer a fix (or a start to one as its not the prettiest).  The end of the technet posting suggests that the issue lies with calendarv4.css found in the hive.  I decided to devote a few hours to digging in with the IE developer tools (both IE7 and IE9).

I assumed that this was probably one of the usual IE7 bugs with  haslayout and all the above so I started there.  I tried everything from zoom to height, to changing the display to no avail.  So lets assume that the calendar items are on the printout (but off the page).  A little absolute positioning some and I could get it to show up, but not on the calendar grid.  Slowly I tweaked it and saw the items disappear behind.  Maybe z-index, nope, maybe if I float it, nope.  Finally I decided to toss the style-sheet into the w3 validation tool.  Hey, there’s an error with overflow-x…overflow could cause the items to clip improperly and there are overflows all over calendar v4.  Why not mess with that.

Finally I was able to find something that would work.  I started out throwing the anvil at it

body *
{
overflow:visible !important;
}

Hey it worked, but I don’t want to have it affect anything outside the calendar. After a little more digging I settled on:

<style type="text/css">
@media Print
{
  .ms-acal-rootdiv * {
    *OVERFLOW: visible !important
  }
  .ms-acal-item {
    *OVERFLOW: hidden !important
  }
}
</style>

Toss that in however you prefer (content editor web part, additionalpagehead UserControl or what have you) and voila, you can print 2010 v4 calendars in IE7.

I pretty much stopped as soon as I had something that worked and was isolated to the calendar blocks, so this could be tuned more to find the actual style that breaks in IE7, but that’s more time than I want to devote to this.

SharePoint 2010 – Lost View Breadcrumb with Multiple Webparts on List View Pages

Have you ever tried to add a Content Editor web part to a 2010 list view say with instructions for the list only to find that you lose the Views dropdown in the breadcrumb?

We had such views on many lists in our MOSS environment only to run into this loss of functionality when we ran through the upgrade. I’ve scoured the internet and picked apart the views to figure out a workarounds.

The first thing I came across was this article/product by Pentalogic:

http://blog.pentalogic.net/2011/03/disappearing-view-selector-menu-sharepoint-2010/#more-1997

This got me started on the way to finding a good solution to the problem. I’ll admit that I spent quite some time playing with reflecting the ListTitleViewSelectorMenu as described to alter the Visible field/property. I was largely unsuccessful as I really didn’t want to put the time into something that could break with an update or service pack. I was about to give up when I read that the ListTitleViewSelectorMenu really uses the ListViewSelectorMenu for the actual rendering.

Instead of reflecting the sealed private property, why not cut to the chase and just add in a second non-hidden ListViewSelectorMenu? Sprinkle in some generic controls for the separator and styling, a touch of logic to ignore the case where there is only one web part and success we have our drop-down back.

I largely want to credit the Pentalogic folks for leading me heavily down the right path but I did want to share a method of getting around this without using reflection. Its not the cleanest as you’ll have two of the same basic control on the page with one hidden, but its more future proof.