ddwrt:IfHasRights() and site permissions

There's plenty of blog articles out there about using the IfHasRights() function, including a list of all the possible permission entities. But one thing I didn't find and had to work out for myself is the fact that the IfHasRights() function is executed at the site permissions level, not the list level.

For example, in the site I'm developing I had a group set with Read access only as the default site permission, but for a custom list gave them Contribute access. On the custom display form I have a block that should only be visible to users with edit access, i.e. IfHasRights(4). This doesn't work for people who are in this group because at the site level they don't have edit access.

The upshot is that if you are intending to have different levels of access within a site and are using IfHasRights(), you will need to give the users the highest level of access required for whatever list, and then reduce their access level for the elements they won't have access to.

SharePoint 2010 Publishing Site Gotchas

Just been playing with SharePoint 2010 Publishing sites and have found a couple of "gotchas", or items of interest where Microsoft have made little mistakes:

The first one relates to the default Master page for a Publishing Site. It is called "nightandday", however inside the master page and the associated css file, there are two spellings:

nightandday - attached to the body tag

nightanday - attached to the left navigation menu

If you are creating a new custom master page based on the nightandday master, be sure to update both class names to your new name.

The second one relates to the new themeable styles feature. This is where you can add 'commands' to the css file to tell SharePoint what to do with the colours when a site administrator changes the theme of the site.

The basic command is:

/* [ReplaceColor(themeColor:"Dark1")] */ background-color: #000000;

Adding this line to a css definition tells SharePoint to set the background-color of the relevant tag to the Dark1 colour of the site's theme.

There are 12 definable colours with five generated variations each (Lightest, Lighter, Medium, Darker, Darkest), giving a total of 60 colours to choose from for styling your site (not including all the other variations that can be created using extended commands such as tinting).

In the nightandday.css file, there are instances of a non-existent variation being used, e.g. Accent6-Light. SharePoint ignores the variation and the resulting colour is the base colour, i.e.:

Accent6-Light === Accent6

The below image shows the full colour table when the site theme is set to "Classic":

Creating new SSP with host headers

I've just spent several hours banging my head against the desk trying to set up a MOSS development environment, and not being able to access the newly created SSP. It has nothing to do with permissions (couldn't access with the account that was used to create the SSP), or having the SSP name the same as the App Pool name.

What was the issue was that I was being tricksy and using port 80 with all three of the sites (SSP Admin, MySite and Portal) and using host headers to identify them. Without any changes, this causes a 401.1 error because in Microsoft's words: "...the Web Site uses Integrated Authentication and has a name that's mapped to the local loopback address."

In the Microsoft KB article, there are two fixes, both involve editing the registry:

1. Specify host names in the BackConnectionHostNames multi-string value, or
2. Disable the loopback check.

The second one is easier if it's a dev environment, but the first is preferred if using NTLM authentication.

Add album to amarok playlist remotely

Completely different track here, this is more for my own reference until I get around to creating the bash script...

I've just discovered the need to manipulate amarok remotely through SSH and came across DCOP which is really cool.

The first problem is when you login in via SSH, DCOP is not running in your session because it's not a KDE session. You can connect to the one that is already running, by adding the '--user `whoami`' parameter to each DCOP call. I just created an alias to automatically do all that:
alias damarok='dcop --user bruzie amarok'

Get list of tracks for an album:

damarok collection query "select url from tags, album where tags.album = album.id and album.name = '<album name>' order by track" | sed 's/^\./"/g; s/$/"/g' > playlist

Then replace the newlines with a space:

sed '{:q;N;s/\n/ /g;t q}' playlist

Which leaves me with a nicely formatted list of tracks to paste into:

damarok playlist addMediaList [ <tracklist> ]

So I can start playing them:

damarok player play

Filter linked data source based on the current date

If you use a linked data source for your fancy page, but need to only show "current items", you need to manually edit the SelectCommand CAML attribute of the SharePoint:SPDataSource node for the relevant list:

<View>
  <Query>
    <Where>
      <Gt>
        <FieldRef Name="EventDate" Type="DateTime"/>
        <Value Type="DateTime">
          <Today OffsetDays="-7"/>
        </Value>
      </Gt>
    </Where>
  </Query>
</View>


OffsetDays allows you to specify an offset from Today. In this case it is one week in the past (to show recently "expired" items). Don't forget to htmlencode it!

Get Workflow TemplateID

On my custom display form for a list I want to create a link to the Start Workflow page of a specified workflow. Getting the URL is simple, open an item and select to start the desired workflow. Copy the resultant URL and use it on the custom page (after sanitising the Source parameter to make it generic or to add an XSL parameter).

However, one of the required URL parameters is the TemplateID of the workflow, which changes every time it is edited. This is an annoyance if you are in active development and the workflow is being updated regularly.

So what we ideally want is the ability to get the workflow TemplateID from code. Luckily for us, MOSS provides the GetTemplatesForItem method of the Workflow web service. I use Darren Johnstone's JavaScript API for SharePoint services. Darren didn't implement the Workflow web service so I had to create it myself (only implemented the GetTemplatesForItem method so far).

The GetTemplatesForItem method only takes one parameter, the full URL of an item, e.g. 'http://moss2007/sites/WorkflowTestSite/Shared Documents/doc1.docx'. If the item is in a list (and not a library), the ows_FileRef attribute of the item is required, e.g. 'http://moss2007/sites/WorkflowTestSite/Custom List/23_.000'.

The returned XML includes information about the workflows attached to the item. To get the templateID, we use a simple jQuery selector with the name of the workflow:

workflows = new SPAPI_Workflows(GetRootUrl());

wfitems = workflows.getTemplatesForItem("http://moss2007/sites/WorkflowTestSite/Custom List/23_.000");

$(wfitems.responseXML).find("WorkflowTemplate[Name=Name of Workflow] [nodeName=WorkflowTemplateIdSet]").attr("TemplateId")

Of course if all we are really wanting is the URL to get to the start workflow page, we could simply use:

$(wfitems.responseXML).find("WorkflowTemplate[Name=Name of Workflow]").attr("InstantiationUrl")

Create list columns via Web Services

I have just spent a day up to my armpits in JavaScript, specifically JavaScript for creating columns on custom lists for a site configuration utility (where the team I was working in doesn't have developer level access to the farm).

The bulk of the work for creating lists and libraries was done by my predecessor but the scope for adding columns to a list was restricted to adding existing site columns. I need to be able to automatically create new list columns.

Using the UpdateList method of the Lists web service makes this quite simple. The tricky part is working out what parameters you use to create the fields (also applies to updating).

The CAML query for creating a field is of the format:

<Fields><Method ID="1"><Field [attributes]/><Field [attributes]/></Method></Fields>

There are lots of attributes to use for the node, but these are the common ones:

• Type: Corresponds to the column type in the Create Column screen (more details below)
• Name: Internal name of the field (replaced with the internalised version of the Display Name, see this post).
• Display Name: The visible name of the column
• Required: "TRUE" or "FALSE", whether or not this column must contain information (not applicable to Yes/No or Calculated columns)
• Description: The column description

Other attributes are used depending on the column type (with typical examples):

• Single line of text
  
  
  • Type="Text"
• Multiple lines of text
  
  
  • Type="Note"
  • AppendOnly="TRUE" (append changes to the field, but only if versioning on the list is enabled)
  • RestrictedMode="TRUE" (defines whether users can use normal rich text, or enhanced rich text)
  • RichText="TRUE" (rich or plain text)
  • NumLines="6" (number of lines to display to the user while editing)
• Choice
  
  
  • Type="Choice"
  • Format="Dropdown"
  • FillInChoice="FALSE"
  • Mult="FALSE" (sets multiple selection)
  • <CHOICES><CHOICE>Choice 1</CHOICE><CHOICE>Choice 2</CHOICE></CHOICES>
  • <Default>Choice 2</Default>
• Currency
  
  
  • Type="Currency"
  • Max="321" (maximum value)
  • Min="123" (minimum value)
  • Decimals="0" (number of decimal places)
  • LCID="1033/5129" (currency format, 1033 is USA, 5129 is NZ)
• Date and Time
  
  
  • Type="DateTime"
  • Format="DateOnly"
  • <Default>[today]</Default>
• Lookup
  
  
  • Type="Lookup"
  • List="Lists/[List Name]"
  • ShowField="Title"
  • Mult="FALSE"
• Yes/No
  
  
  • Type="Boolean"
  • <Default>Yes</Default>
• Person or Group
  
  
  • Type="User"
  • UserSelectionMode="0" (all people)
  • ShowField="ImnName" (Name with presence)
• Calculated
  
  
  • Type="Calculated"
  • ResultType="Text"
  • ReadOnly="TRUE"
  • <Formula>=If([ECM Status]="Draft","Work in progress","Submitted")</Formula>
  • <FieldRefs><FieldRef Name="ECM_x0020_Status"/></FieldRefs>

Use friendly 'developer' column names

When you create new columns in your SharePoint site, an internal name is created from the entered display name. SharePoint uses this internally for what it does and if you use SharePoint Designer to create custom pages for your lists, document libraries, etc. then this internal name is what you interact with.

The internal name (FieldName) is generated by replacing any spaces with _x0020_, so for example, if you create a column called Registration of Interest, the generated FieldName will be Registration_x0020_of_x0020_Interest. You can see this by looking at the field parameter in the URL when editing the column:

In this case, SharePoint encodes the '_' as %5F, which makes it even more messy.

Now if you only work with out of the box configuration through the browser then that's fine, you don't need to worry about the FieldName. But if you work with SharePoint Designer then it becomes horrible to look at, less than to use.

What can you do? If you rename a site column, all you are doing is changing the display name, the FieldName remains the same. So when you create a new column, give it the name you want to use internally, then change it afterwards to what you want it to display. In our above example, we would create the column by calling it RegistrationOfInterest (alternatively RegOfInterest or even RoI). Once the column is created we can then rename it to Registration of Interest but the FieldName will still be RegistrationOfInterest. A lot easier to use.

You can also use this trick when creating lists and libraries to create friendlier URLs. A list called Training Providers will display /Training%20Providers/ in the URL, but if you name the list TrainingProviders on creation, then rename it, the URL portion will remain /TrainingProviders/.