SPSecurityTrimmedControl – Possible Values for PermissionsString

I’m working on an Intranet where virtually everyone will be a Contributor.  We’ve built custom navigation paths to customized forms for the content input, so we want to hide the “View All Site Content” links on every page.  We want to hide it from everyone except the users who have Full Control.

The master page, by default, shows this link as follows (formatted for readability):

<Sharepoint:SPSecurityTrimmedControl runat="server" PermissionsString="FullMask">
    <SharePoint:SPLinkButton id="idNavLinkViewAll" runat="server" NavigateUrl="~site/_layouts/viewlsts.aspx" Text="<%$Resources:wss,quiklnch_allcontent%>" AccessKey="<%$Resources:wss,quiklnch_allcontent_AK%>"/>

Easy to find in the master, but what values are available for PermissionsString?  Not an easy thing to find, but if you look at the bottom of this MSDN page at the Community Content, you’ll see the available values.  Thanks to Zac Smith in NZ for posting this!  (Here’s a link to his original blog post.  The one in the MSDN page is no longer valid.)  We’ll experiment with what value works best in our situation.

List Permissions Site Permissions Personal Permissions

Setting Multi-Select Widths in a SharePoint EditForm.aspx Using JavaScript

<UPDATE date=”2009-01-25″>
I now have a function in my jQuery Library for SharePoint Web Services called SPSetMultiSelectSizes which accomplishes this in a more robust way, taking into account the font, font size, etc.

When you have a multi-select lookup column in a list, SharePoint provides you with a control that shows two select boxes next to each other on EditForm.aspx.  There are two buttons (‘Add >’ and ‘< Remove’) that let you move values between the two, selecting or deselecting the values.

By default, the select boxes are a fixed width and, in many cases, not wide enough to let your users see the values very well.  The following JavaScript will set the widths of the select boxes based on the length of the longest value available in the lookup.  It isn’t fully multipurpose, as I wrote it for a specific instance with a particular set of branding (font size, spacing, etc.) but it ought to give you a very good start to use it yourself.  (With the fonts that I was using, I found that 7 times the number of characters in the longest value worked well to calculate the right width.  You’ll probably need to experiment.)  Pass in the name of the column you want to adjust.

// setSelectWidth: Set the width of a lookup column's select box based on the values it contains
// Arguments:
// columnName: The name of the column which is being displayed in the select box
function setSelectWidth(columnName) {

  var charFactor = 7; // Approximate pixels per character

  // Left side
  leftColumnSelect = getTagFromIdentifierAndTitle("select","",columnName + " possible values");
  if(leftColumnSelect != null) {
       leftColumnSelectDIV = findParentElement(leftColumnSelect, "DIV");

  // Right side
  rightColumnSelect = getTagFromIdentifierAndTitle("select","",columnName + " selected values");
  rightColumnSelectDIV = findParentElement(rightColumnSelect, "DIV");

  // Find the longest value
  var longestValue = 0;
  for (var i=0; i  leftColumnSelect.options.length; i++) {
    if(leftColumnSelect.options[i].text.length > longestValue) {
      longestValue = leftColumnSelect.options[i].text.length;
  for (var i=0; i < rightColumnSelect.options.length; i++) {
    if(rightColumnSelect.options[i].text.length > longestValue) {
      longestValue = rightColumnSelect.options[i].text.length;

   // Set the widths of the two selects and their containing DIVs
   var newWidth = charFactor * longestValue;
   leftColumnSelectDIV.style.width = newWidth;
   leftColumnSelect.style.width = newWidth;
   rightColumnSelectDIV.style.width = newWidth;
   rightColumnSelect.style.width = newWidth;

This function builds on the getTagFromIdentifierAndTitle function provided in an excellent blog post I’ve referenced before over at the Microsoft SharePoint Designer Team Blog.  I’ve also created a findParentElement function you’ll see called above, which finds a specific parent element for a tag.  The code for this is below:

// findParentElement: Find an object's specified parent element
// Arguments:
// thisElement: The element you want to search from
// parentTag: The parent tag you want to find

function findParentElement(thisElement, parentTag) {
  var currentElement = thisElement;

  while(currentElement.tagName != parentTag) {
    currentElement = currentElement.parentNode;

    if(currentElement.tagName == parentTag) {
      //alert('HIT:' + currentElement.tagName);
      return currentElement;
  return null;

Changing Page Layout “Value does not fall within expected range.” Error

We just did a Site Collection backup from a development environment into a staging environment.  The development environment can only be accessed through a VPN while the staging environment is available through the Internet.

When I went to change the page layout for a site’s welcome page (default.aspx), I got the following error:


After some research, it seems that the page in the staging environment is probably still pointing to the page layout on the development environment. See the posts below for some thoughts on this.


Both of Gary and Vince are talented guys and I trust their analysis of the issue.  In my case, I’m just going to delete the sites and rebuild rather than trying to run the fixes they suggest.  (My client isn’t allowing me access to the server in staging.)

Passing Query String Values as Part of the Source Query String Parameter in SharePoint

SharePoint has a nice capability on many pages where, if you pass a Query String parameter named Source with a value of a page URL, the user is returned to that page when they are done with the activity.  An example would be when a user clicks on an ‘Add new document’ list on a site where they are a contributor.  The current page’s URL is specified as the Source parameter, and when the user is done adding the document, they return to the current page.

There are times when you’re sending your user off from a page that relies on its own Query String values to configure it.  So, how do you pass those values along with the source so that when the user gets back, they see the page configured correctly?  The trick is a little encoding magic.  Configure your URL to look like something like this:

<a href="{concat('/PG/Policy%20Guidance/Forms/DispForm.aspx?ID=', @ID,
         '&Source=', $URL,
         '?Series=', $Series,
         '%26ContentArea=', $ContentArea)

This will evaluate to something like this URL:


By placing a question mark (?) after the Source URL value and encoding the ampersand (&) between parameter/value pairs as %26, you can ensure that those values are passed back to the Source URL when the user returns to that page.  This will also work if you are building your own forms and are using the ddwrt:GenFireServerEvent(‘__redirectsource;’) function.

Technorati tags: , ,

SharePoint Designer: Useful Tool or Spawn of the Devil?

OK, so you know how I’m going to come down on this, but I got your attention, right? In fact, at almost every large client I work with, the latter seems to be the opinion.  The rules are usually: No SharePoint Designer use in staging and production.  Period.

This stems from a fundamental lack of understanding of what SharePoint Designer is and what it allows you to do.  It’s unfortunate, because as the middle tier option to development in SharePoint, it facilitates the development of everything from page layouts to full-fledged applications with custom forms, navigation, and reporting.

A little history is probably useful here. SharePoint Designer is indeed FrontPage all grown up.  When Microsoft released SharePoint Designer, it was the newest version of FrontPage and a part of the Office 2007 suite of productivity tools.  At the same time (or very recently afterward), Microsoft forked FrontPage into Expression.  Initially SharePoint Designer and Expression looked like they were identical products, but Expression didn’t have support for SharePoint and it was targeted at designers more than developers.  (It has since been enhanced to be even more valuable in that space.)

So the fact that SharePoint Designer comes from FrontPage is probably a part of the prejudice. It was certainly true that letting a random user loose on older server platforms could cause utter havoc for the IT folks.  Those platforms usually didn’t have the permissions layers that SharePoint provides, however, and FrontPage was probably too liberally given out.  Enter the guard rail mentality. (I just hit the right one, let me pull hard left and — oops, I just hit the left one, so let me pull hard right, and…  You get the idea.)  FrontPage was bad, so SharePoint Designer, as its older sibling, must be even worse.

Another contributing fact to this whole picture is the experiences with SharePoint 2003 (or even earlier versions like 2001, Tahoe, TPU, etc.)..  In SharePoint 2003, there were serious issues with pages becoming "unghosted" and being "moved into the database".  This *sometimes* caused performance issues.  If you edited a page in FrontPage, it became unghosted.  Again, not in itself a bad thing, but FrontPage was the "cause".  This is no longer the case with SharePoint 2007.  While pages can be customized away from the site definition, there is not performance hit and they can be reverted back to the site definition easily if needed.

So what’s the case for using SharePoint Designer on SharePoint 2007 (whether it be MOSS or WSS)?  Well, you can do a heck of a lot without a "real" developer with faster turnaround cycles.  Here are some examples:

  • Customizing the master page and CSS — The master page drives the overall structure of a site’s pages. (It can be used at a single site level or at the Site Collection level.  Your choice.)  The master page is simply an HTML structure with a lot of SharePoint controls embedded in it.  The default master page is what exposes the tabbed navigation the welcome message, the search bar, etc. in the default site.  Because we’re in the 21st century, it, like most things, is all text.  (You can edit it with Notepad.)  However, SharePoint Designer "understands" all of the controls and gives you contextual menus and help to configure them.
  • Creating layout pages — Page layouts define the structure of pages that are set to use them.  Wait, this sounds like the master page, but it isn’t.  Page layouts inherit the master page and then can provide additional internal structure and Web Parts.  (If there’s even a chance that you will use variations, get in the habit of using page layouts — you’ll need them.)
  • Adding Data View Web Parts to pages — Data View Web Parts (DVWPs or Data Form Web Parts) are, as I’ve said many times, the Swiss Army Knife of Web Parts.  They give you total freedom over how you display content and can connect to many types of Data Sources.  You can (though you wouldn’t want to) edit the XSL for DVWPs through the UI, but again, SharePoint Designer is fully DVWP and XSL aware, so you really want to use it.  You can only add DVWPs to pages using SharePoint Designer.
  • Workflows — There’s a middle tier of workflow development (between the UI and Visual Studio) where I would argue you can do 80% of what you’ll need.  And SharePoint Designer is the tool that you need to do it.  There is a nice If-Then-Else editor in SharePoint Designer that lets you do this very well.

Now all of these things (except workflows — they are in a class by themselves in many ways) can be edited through the UI if you are a Site Collection Administrator.  You simply navigate to the containing location (Master Page Gallery, Pages folder, or whatever), download the file to your hard drive, open it in Notepad, and edit away.  You can then upload the file, check it in, and approve it (where required) and you have a new version in place.  Odds are very good that it won’t work because there’s far too much room for error, but you’ve just edited a file without using SharePoint Designer.  If you are a masochist, maybe this is the way to go for you.

Keep in mind that in SharePoint, EVERYTHING — let me repeat — EVERYTHING is security trimmed.  If you don’t have permission to access something through the UI, you won’t be able to access it through SharePoint Designer, either.  So you can’t just open the root site and delete everything.  If you are a Site Collection Administrator, you have the choice to be this destructive through the UI or through SharePoint Designer, but the average user can’t even open anything if they have SharePoint Designer.

So what does prohibiting SharePoint Designer protect?  Not much, really.  A malicious user with permissions can wreak havoc.  An untrained user with permissions can wreak havoc.  And both of these statements are true without SharePoint Designer.  With SharePoint Designer and a bit of training, your users (and I wouldn’t suggest that you need more than a few people with SharePoint Designer and the permissions to use it) can build wonderful functionality.  They can’t touch anything on the server.  Nothing in the file system.  No server settings.

When you add these things up, does SharePoint Designer sound like a useful tool or the spawn of the devil?