So, the case management system I’m working on has a ‘Mailbox’ library. Really, it’s just an email enabled document library, with the address set to the name of the case. Anyway, when emails are received into this list, we’d like to show the subject, sender, cc, to addresses, and so on. It turns out that email enabling a document library does in fact add columns for those properties (but they’re not automatically added to the default view).

Neat! Until you start looking at the code itself – then it sucks…

Disclaimer – This is still on an SP1 system. Hopefully some of this may have been fixed.

Okay, so what are the problems with this page?

• The user’s email addresses are hyperlinks using ‘Mailto:‘s, which is actually pretty nice. However, the Mailto:s are terminated with a spurious ‘>’ character. It’s supposed to terminate the anchor tag; instead it is in the href itself.
• The leading ‘<‘ character for most of the email addresses is not part of the mailto hyperlink. The trailing ‘>’ character is.
• What’s with all the semi-colons?

We also had our own peculiar requirement – we wanted the Mailtos to CC the case itself. That’s right, click on someone here to send an email, and end up CC the original list! It’s to try and capture more of the email conversation.

To do this, first I needed to get the email address of my list. The first part of that (before the ‘@’ ) is easy enough – it’s a property of an SPList item. But I needed to get the rest of the address, and to output it in my page as a string. I ended up writing a custom Web Control:

The guts of this control are in the lines:

SPList list = SPContext.Current.Web.Lists[this.Attributes["List"]];
emailAlias = list.EmailAlias + "@" + SPFarm.Local.Services.GetValue<SPIncomingEmailService>("").ServerDisplayAddress;

First, we get the list, based on a ‘List’ attribute of the web control. Then we get the full address from that list, and from the incoming email service object for the local farm. Trust me, it works, even if the second line is a bit scary!

So, now able to get the email address for my list, I needed to tidy up my view. I’ve been using jQuery a bit recently as it is very good at finding things on the page; this seemed an appropriate use again. The code I developed was:

To go through it line by line:

First, I use my new web control to get the email address of the list.

var emailAddress="<Case:CaseEmail runat='server' List='Mail Box'/>";

Then, when the page is loaded, I run a query for all Anchors that have a hyperlink (href) starting with mailto:

$(document).ready(function() {
$("a[href^='mailto:']").each(function(){

For each of those matched anchors, I get the inner HTML and…

• I remove the ‘>’ at the end of the hyperlink
• I remove the ‘>’ that’s actually in the mailto!
• If the mailto isn’t to the list’s address already, then we add a CC to the hyperlink.

var inner = this.innerHTML;
inner = inner.replace(/>$/,"");
this.href = this.href.replace(/%3E$/,"");
if(this.href.indexOf(emailAddress) == -1) {
this.href = this.href.replace(/$/,"&cc=" + emailAddress);
}
this.innerHTML= inner;

Next, I run another query to get the cells of my listview.

$("td[class='ms-vb2'] > div").each(function() {

For each one I replace the end anchor tag and any spurious semi-colons with an end anchor tag and a ‘>’

var inner = this.innerHTML;
inner = inner.replace(/</a>;+/gi,"</a>&gt;");
this.innerHTML= inner;

This ultimately produces:

A tidied up view! I’ve also used my web control to display what the address of the list is (and provide yet another mailto) in the description of the page. Naturally, the problem with this approach is if users go and create new views on this list, they won’t have my JavaScript in them – but this should do for now.

Conclusion – jQuery does seem to provide a very powerful way of controlling parts of the SharePoint user interface that would be very troublesome to access/control in another method. Changing pages like this on the client after download does offend my sense of ‘rightness’, but it works pretty well.