Folder Search Scopes

There's something that drives me nuts every time I need to use it, but because I don't do it often I always forget what it is I do to fix it. This is setting up Search Scopes.

There's plenty of information out there regarding how to set up a search scope for a folder so I'm not going to go into those details, but one thing that comes up is the dreaded "xyz Items, Total: 0" error. That is, when you set up a search scope, an approximate number of items within the scope is returned, but after a refresh, there is still 0 items in total - what gives?

Well, the basic answer is that when you set up a folder search scope, you need to use the url of the default server mapping. In the case I've just worked with, the default server mapping is http://appname.company.com, but because it's available externally the urls I work with are https://appname.company.com. When creating the rule for the search scope, I had to enter http://appname.company.com/sites/collection/Lists/listname for the scope to pick up the valid items.

Nintex 2007 - Query Workflow Tasks list for approval comments

When using the Request Approval action in Nintex workflow, you can use the Approver Comments field for notifications. However, it's pretty ugly when there are multiple approvers, e.g.:

Joe Bloggs (Approved) 10/05/2011 8:05 a.m. - 10/05/2011 8:05 a.m.
(DOMAIN\jbloggs) This is good to go!
Fred Dagg (Not Required) 10/05/2011 8:05 a.m. -

What people find is that they don't want all that extra information, just the comments.

Nintex provides a tutorial for doing this by querying the Workflow Tasks list directly for the ApproverComments fields and putting them into a collection variable. The key is to set up the filters for the query:

• Workflow Item ID: ID
• Workflow List ID: List ID

This is all well and good if there is only ever one approval workflow performed on an item. What happens if the approval workflow is run multiple? Querying the Workflow Tasks list will bring back the comments from all instances of the workflow. By default, there isn't a way to differentiate between the workflow instances because there isn't a "Workflow Instance ID" field in the tasks list.

So how can we get around this? It's quite simple - create a unique task name for each instance of the workflow and perform the query based on this unique task name:

1. Calculate a date: Use date when action is executed and include time. Store the ISO 8601 date string into a text workflow variable, e.g. Workflow Start ISO
2. Request approval: Set the task name to "XYZ Approval - Workflow Start ISO", i.e. include the workflow start variable in the task name.
3. Query list: Add filter rule for Title = "XYZ Approval - Workflow Start ISO", while still including the original filters from above.

This will bring back the ApproverComments for all tasks relating to this workflow instance. You can add an additional filter rule where ApproverComments is not null to cut down the results (e.g. if there are multiple approvers, but you are only interested in the first response, the others are blank).

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!