SP2010: Delegate control for GlobalSiteLink3 not working / showing

Technical / June 4, 2012 / Jasper Siegmund / 0

I spent quite some time today on a question I was asked. In an existing solution, we added a custom action (button) to the standard menu (the dropdown menu on your account name in the right upper corner of a site). This button was a “Add site to favorites” custom solution. The request was: can we move that button to the same place the default “I Like it” and “Tags & Notes” buttons are? I didn’t think that this would be such a problem. But I was wrong due to my good friend: the Sandbox.

There’s two important things to know. First of all, the default “I Like it” and “Tags & Notes” buttons are not in the ribbon, although they appear to be. That’s because the area shown by default, the “Browse” tab, is not an actual ribbon tab. I don’t exactly know why this choice was made, probably because you might want to disable the ribbon without losing this area. The area is defined in you master page instead.

Ok so where do those buttons then come from? We’ll they’re in a feature called ‘SocialRibbonControl’. Inspecting the element files learns us that the buttons are defined twice: in SocialDelegateControl.xml and SocialRibbonControl.xml. The ribbon buttons are shown in a document library, they’re not of interest at this point. The delegate controls tell us that we’re dealing with delegates here.

The delegate control being used is GlobalSiteLink3. So we now know what to do, right? Create a new feature, implement a custom control and use a Control node to overwrite the delegate with our control. Easy peasy. Sure. When you’ve got farm access.

For some reason, Microsoft decided to mark the DelegateControl definition for GlobalSiteLink3 with Scope=”Farm”. So the only features allowed to overwrite it are farm scoped features. And there’s the second important thing to know: farm scoped features are not allowed in a sandboxed environment. Why scope the delegate Microsoft, WHY!? I really don’t understand why you would limit us like that. What’s the security risk here? By the way, this scope is only applied to GlobalSitelink2 and GlobalSiteLink3.

I checked, hoping that they might have changed this in Office 365, but unfortunately they did not. I’ll open up a ticket about that, but untill it’s fixed this means you’ve got two options:

1. Deploy in combination with a custom masterpage in which you remove the Scope=”Farm” attribute. Then you can deploy your site scoped feature and overwrite the delegate.
2. Deploy as a farm scoped feature, but as stated that will only work for non-sandboxed solutions.

But both aren’t good options for me at this time. Perhaps Microsoft will come up with a solution. Changing the v4 masterpage definition for Office 365 would be the easiest, but the chance of that happening soon is… well… not that big.

Update: here’s the O365 community post; http://community.office365.com/en-us/f/153/p/55979/201597.aspx#201597

#o365, #office365, #SharePoint, #SP2010, sharepointonline

Jasper Siegmund