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.
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.
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
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).