Fix the DocID behaviour in SharePoint to work more like a real ECM platform

It annoys me that SharePoint has some great Enterprise Content Management features baked right into the product… Such as “in place records” and Document Routing Engines… right beside some forehead-slapping features that make absolutely no sense at all. The one that tweaked my melon  as soon as I saw it was the DocumentID feature… it’s a great idea, lets people use a static URL to find and load documents wherever they are in SharePoint – it even uses the search service to find it in the enterprise if it can’t see it in the current Web App. Awesome! Brilliant!

So, consider for a minute: how would you set it up? If you had a business need or decision that drove a SharePoint ECM solution, you’d want to make damn sure that the “Static Links” used to link to documents (you know, the ones that are the same no matter where the document lives) are the ONLY ones that get used. The whole point behind an ECM is that you can always find your content… but if people are moving the content around in a SharePoint site, the normal URL is constantly changing (but not the DocID).

So the way Microsoft have set up the “feature”, it adds an extra column to each document library called “Document ID” – this contains the DocID number and a link to the document using the “DocIDRedir.aspx” page. The problem is, this is a new column. It does not update the existing links in the “Name” column of your normal document library, it just adds another column. So now users have 2 columns. One with the Document name, the Edit Control Block and all of the nice UI functionality users have come to expect from SharePoint. The other column is some cryptic 12-digit string that nobody understands. Imagine the change management required to train people that even though they can see the nice pretty link, they must use the ugly cryptic string. You’d call yourself a change management expert if you got a 50% success rate.

image

So what I did was try to see if there was a way to use jQuery to solve the problem – as it can rewrite DOM elements, I figured it would be my Swiss army knife in this case.

image

Bingo! User experience is the same as normal, but the link is now the same as the DocID Column… so if someone clicks on the link to open the document, or they right-click on it and send the link to a Mail Recipient, they’ll get the DocID link – and have a permanent link to the document. Cool, huh!

Here’s the code

<script type="text/javascript">
$(function(){

    $.each($('a [href*="/_layouts/DocIdRedir.aspx?"]'), 

function(){

        var $t = $(this);

        $t.parent().hide().siblings('td.ms-vb-title').find('div.ms-vb a').attr('href', $t.attr('href'));

    });

$("div[name='_dlc_DocIdUrl']").parent().hide();

});
</script>

Initially, I looked at trying to move the ECB using SP Designer, but that does not fly – You can move it on a SharePoint list without an issue, but if you try on a Document Library you get “Send To undefined” appearing on the ECB (and none of the file-specific functions work). This solution was “Plan B”.

Firstly, I want to point out that this is not my work – in fact, I’m still working out how jQuery functions and what it can do (and I’m not a developer) – but the community at the jQuery site is brilliant and was kind enough to help me out, once I gave them the DOM structure from the page I was looking to fix.

Secondly, it does not address all of the problems. The Edit Control Block (ECB) functionality still pulls the old URL from the page – in a production system, this would need to be fixed as well. But the Core is there, and I don’t see it would be hard for a developer to override the ECB with the pluggable architecture it has. The Office clients remember the normal link, not the DocID link – This would mean the “Recently Modified” list in your Office client would not reflect the DocID links, but rather the links they “resolved to”… so if the document moves, the “Recently Modified” link breaks.

Finally, it’s a jQuery solution – so it needs to be applied to all Document Library pages (eg through a JS include on all pages, or something) and jQuery needs to be loaded on the page. I have not tested it on other page types, and I do not know if it would randomly hide a side nav menu (for example), but it works for me. There are probably smarter ways to do this, but this is what I can do with a big roll of duct tape (and it works at demo time).

B

Advertisements

About Brad Saide

I'm a SharePoint consultant. I'm also slowly going bald, seem to have a permanent spare tyre around my waist and enjoy socialising with friends over a beer or 10. The last 2 may possibly be related. Started working with SharePoint when the first version was in limited beta release (participated in the Technology Adoption Program while at Woolworths) and have been committed to the adoption of the technology as a business enabler ever since.
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Fix the DocID behaviour in SharePoint to work more like a real ECM platform

  1. Eric Xue says:

    Well described as always and thanks for sharing!

    One thing for sure here is that the jquery script shown the above won’t hide the side nav menu since it only looks for the href with specific path ‘/_layouts/DocIdRedir.aspx?’ in there.

    All best

    Eric

    • Brad Saide says:

      Thanks Eric – The main point behind the statement was to get across the fact that I have not tested it, and if you intent to use it, you should… before rolling it out into Production 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s