Where’s the Darn Permission Roles Page?!?!?

This is a little one, but a time saver all the same.  I can never seem to find the “right” navigational route to the page which shows the permission levels (I think of them as roles and the page name backs me up!) in SharePoint.  It’s the page at /_layouts/role.aspx.  So:


From this page, you can check the underlying permissions for each permission role as well as create new roles.

Happy Groundhog Day!

SharePoint Saturday Boston – March 14, 2009

Another name drop and tip ‘o the hat to Mauro Cardarelli for bringing this one to my attention.  SharePoint Saturday is coming to Boston.  I’m going to see if I can’t get in as a speaker to talk about my SharePoint Designer DVWP stuff.  Working title: Developing with SharePoint Designer: The Middle Tier, Focus on Data View Web Parts (DVWPs).  I know it’s a mouthful, but if all goes according to plan, I’ll be putting together some more Focus on… bits in the future.

What topics would you like to hear me cover?  Of course, if I do speak I’ll make the materials available for those of you out on the ‘Net.

If you’re in the New England area and can afford a Saturday in your schedule, you should check SharePoint Saturday out.  It’ll be held at the Microsoft office in Waltham, MA on March 14, 2009.

SharePoint Saturday is sponsored by the gang over at the International SharePoint Professionals Association.

PerformancePoint Moving into the SharePoint World

My colleague Mauro Cardarelli posted about this the other day:

By now, you have probably heard about Microsoft’s decision on the future of PerformancePoint Server (Microsoft Business Intelligence Announcement Q&A).  Kudos to friend Chris Webb for breaking the news… at least to me!

For PerformancePoint jocks, this is probably bad news, but as a SharePoint junkie, it sounds great.  Having even more Business Intelligence (BI) capabilities available in the SharePoint platform can only be good news.

Mauro’s concerns about his closet space aside, he’s right about the dearth of good talent working with SharePoint today.  But will this create a bigger mess or a bigger set of opportunities?  I think the latter.  This will allow organizations that already are using SharePoint to extend that use even further into the BI space.  Many organizations are already storing some of the data that can feed their BI in SharePoint, so the layering on of more tools simply gives them more options.  Yes, it will make the SharePoint platform bigger and potentially more confusing, and no, there aren’t a lot of folks out there who even understand all of what is included currently (myself included — it’s just too big!), but I expect that we’ll see more specialization inside the SharePoint space to make up for it.

Mauro is certainly right (as usual) that it’s some of the “softer” stuff (strong governance, solid information architecture, tight security models) that make or break SharePoint success.  Those things will become even more important as SharePoint’s capabilities expand.  As I always tell my clients, the best SharePoint developer is one who knows when *not* to code, but to take a step back and talk about the underlying business goals, processes, and incentive changes which are going to be required for the technology implementation even to make sense.

Search Results XSL Question

I had a question from a colleague today about how to do an XSL transformation of some search results.  Here’s the query:

Basically, I want to do the following in XSL:

  1. Parse a managed property, urlEncoded, that has the format of http://[doc library]/[filename] to separate path and filename
  2. Take that prefix and concatenate it with ‘/Forms/DispForm.aspx?ID=’
  3. Take that and concatenate it with another managed property, owsidinteger

All this in one big ugly xsl statement.

This is actually pretty simple, if you know how to do it!  Let’s assume some data for urlEncoded like this:

  • http://servername.com/doclib/doc1.doc
  • http://subdomain.servername.com/doclib/doc1.doc
  • http://subdomain.servername.com/site1/site2/site3/doclib/doc1.doc

Those are the three big levels of complexity.  Visiting the excellent reference MDSN article about the ddwrt namespace by Serge van den Oever, we can see that the UrlDirName function may do the trick:

public string UrlDirName(string szUrl);

Returns the directory name of the file in the given URL szUrl. For example, if szUrl is "/a/b/basename.ext", the value "/a/b/" is returned.

With the data above, UrlDirName will return the following:

  • /doclib
  • /doclib
  • /site1/site2/site3/doclib

So the ‘big ugly XSL’ answer is:

<xsl:value-of select="concat(ddwrt:UrlDirName(string(urlEncoded)), '/Forms/DispForm.aspx?ID=', owsidinteger)"/>

The syntax for the hyperlink is something like:

<a href="{concat(ddwrt:UrlDirName(string(urlEncoded)), '/Forms/DispForm.aspx?ID=', owsidinteger)}">
<xsl:value-of select="@Title"/>

Note the squiggly brackets.  I think the most common ‘gotcha’ with using the ddwrt functions is forgetting to do the explicit string conversion.

Site Column Name Truncation in Custom Lists vs. Document Libraries

I think I’ve found an interesting (if you think things like this are interesting) difference between Document Libraries and Custom lists when it comes to the use of Site Columns.  I had some filtering code in a DVWP that ought to have worked the same way on both a Custom List and a Document Library, but it turned out that the underlying column names in the Custom List were truncated but they weren’t in the Document Library.

Here’s what I mean.  I added a Site Column called ‘Management and Administration’ to a Custom List and a Document Library.  (I actually added it to a Content Type used by the Document Library and directly to the Custom List, but that turned out not to be the actual distinction.)  The underlying column name in the Document Library ended up as @Management_x0020_and_x0020_Administration and in the Custom List it was @Management_x0020_and_x0020_Admin.  This caused my filtering code not to work for the Custom List.

The simple workaround was to have two separate XSL templates for my filtering which were fundamentally identical, but took into account the slight difference in the column names.  I ended up calling the two templates “ContentFilterDocLibs” and “ContentFilterLists” to make the distinction clear for future developers.

The truncation in Custom Lists always seems to happen at 20 characters, treating the space as a single character (not the 7 characters in the encoded _x0020_ string).  I’m guessing that this is one of those little things that is still around from having had different sets of developers working on WSS vs. MOSS over the earlier versions of SharePoint.