Determine if a user is a farm administrator

Posted on by
Reply

Sometimes you just need to know if a user is a farm admin; conveniently SharePoint provides a couple of static methods on the SPFarm object to check this:

if( SPFarm.CurrentUserIsAdministrator() ) { ... }

Neat, but one tip – it’s not obvious but it seems that if you want to check this within a content web application, you have to use the method that accepts a boolean and that bool needs to be true:

if( SPFarm.CurrentUserIsAdministrator(true) ) { ... }

Otherwise you will only ever get a ‘false’ response.

Tokenisation and the Ribbon

Posted on by
Reply

A useful post on the MS SharePoint developer blog – “Tokenization in the SharePoint 2010 Server Ribbon“. I always find it a little tricky remembering what token works in which place; this explains it.

In general, and as a reference for myself:

Location ListUrlDir ItemId ItemUrl RecurrenceId SiteUrl ListId Source SelectedListId SelectedItemId
List View Yes No No No Yes Yes Yes Yes Yes
List Form Yes Yes Yes Yes Yes Yes Yes No No

Annoyance: GUIDs for Views must be upper case

Posted on by
1

So, I have a list where I’m using one of the views for my own nefarious purposes; I don’t want users to be able to see it normally, so I set it to hidden in my List Schema. That was fine, and worked.

However, I do need administrators to be able to edit that view – so I gave them a link that would take the to the ViewEdit.aspx page. This worked, except that whenever you tried to save any changes to the view, all you got was an error:

This seemed spurious – “View does not exist” - we’d just looked at the view, so how can it not exist? I tried unhiding the view, and testing, and I found that if I went by my link then I couldn’t save changes, but if I went by the standard UI, everything worked.

Great.

In the end I started comparing differences between the pages you got by my link and the UI. What I found was that some of the GUIDs in the page were, like my link, in lower case.

And that was the problem – the GUIDs in the URL needed to be upper case.

I surmise that someone is comparing strings during the ViewEdit save, rather than the GUIDs that they actually are. #FAIL.

Bloody Stupid SPWeb properties

Posted on by
7

So, like many SharePoint objects, the SPWeb object has a property bag. Unlike many, it has two – Properties and AllProperties.

The problem I encountered with this was that I was trying to set some Search Center settings on a newly created Site Collection, and their capitalization was being persisted wrongly:

newRootWeb.AllProperties["SRCH_ENH_FTR_URL"] = settings.SearchCenterUrl;

This would be persisted as lower case – which was wrong. Lower case capitalisation isn’t the same upper. Nice. Continue reading →

Disable Output Escaping in XSL

Posted on by
Reply

Really, just a reminder for myself, but if you work with SharePoint long enough you’re bound to end up using something like the Content Query Web Part or a Data View Web Part to aggregate and output a rich text source – but all your HTML gets escaped, so it appears content on the page.

The command you want is DisableOutputEscaping:

<xsl:value-of select="somevalue" disable-output-escaping="yes" />

This will cause the HTML to be output unescaped – i.e. as HTML.

Side note: Sometimes people want things like the CQWP to show the first part of the content as a ‘summary’. This trucating content to display in the CQWP or DVWP is difficult; either a) you risk having unfinished tags in the HTML you do emit, or b) you have to strip out all HTML, which can ruin your formatting. a) is a particular problem, as unfinished <table> tags can cause all sorts of weirdness on page.

My preferred option is to have a additional ‘summary text’ box that accepts plain text, and have the author generate the summary manually. That way we avoid outputting HTML like that entirely.

HideCustomAction doesn’t work with the EditControlBlock

Posted on by
1

So, this is a new fact about SharePoint for me – HideCustomAction Feature element doesn’t work with the EditControlBlock. Normally, you add links to menus, toolbars, etc., using a ‘CustomAction‘, and hide them using ‘HideCustomAction’. Works a treat in most of the interface.

However, with the Edit Control Block (ECB) Hide custom action doesn’t work. It looks like ‘cos the menu is rendered by JavaScript, you can’t hide them. Liam Cleary posted a good article about it for SharePoint 2007, and I suspect this will be the same in 2010. It means you’re likely to have to use JavaScript to remove things off the menu :/

Don’t know how I managed to avoid this problem for 4 years!

Converting Enumerations

Posted on by
Reply

I love Enums – but I always have to look up how to convert them to one thing or another – so a reminder for myself:

Here’s my enumeration:

    public enum MyEnum
    {
        Alpha,
        Beta,
        Gamma
    }

And the conversions (each enumeration item has a value (e.g. 1) and a string (e.g. “Beta”):

MyEnum someEnum = MyEnum.Beta;

//Convert to String
string someEnumString = someEnum.ToString();

//Convert to MyEnum again
MyEnum someEnum2 = (MyEnum)Enum.Parse(typeof(MyEnum), someEnumString);

//Convert to int value
int someEnumInt = (int)someEnum;

//Convert int to My Enum again
MyEnum someEnum3 = (MyEnum)someEnumInt;