When adding properties to the Advanced search web part you are bound to know exactly which metadata is included and how it’s spelled. This could be frustrating.
For some reason MS has decided not to help us spell like every other search component would do nowadays.
Consider you have 3 different metadata tags which is all choice or lookup fields. Now, you might want to autocomplete those fields in the Advanced search property restrictions to make sure that the spelling is correct or just to show the users which choices they have.
I implemented this with jQuery-UI which has jQuery-autocomplete included. I also decided to do all the gets by using the SharePoint client OM.
I will not tell you how to define your metadata properties in the search service or how to make them appear in the Advanced search webpart, you can google that
My colleague has created our intranet in SharePoint online. Using standard features in SharePoint we wanted to have a Wall feature (like Facebook) where users could post what ever they wanted.
We decided to use the SiteFeed WebPart. This is a WebPart which is unique for every site, using SharePoint list called “MicroFeed” to provide data. This is the same way as the Microblog is used on MySite.
The SiteFeed WebPart looks quite good and it provides all the functionality we wanted for a Wall feature, such as comments, likes, tagging people and other social stuff.
The SiteFeed Title “Neewsfeed” can’t be changed. This is NOT the title of the standard WebPart control, this is a built in title in SiteFeed WebPart. This title is not hard-coded, but it’s located in a predefined resource, profilebrowserscriptres.resx, which requires hive-access to change. See this blog-post for more information about the resx. Bare in mind that changing the resource will change the SiteFeed Title everywhere.
The WebPart has Chrome Type none by default, which means that the standard WebPart Title won’t be displayed.
I encountered this problem in a WSS 3.0 environment. Hopefully this can help newer versions of SharePoint as well.
My customer has a old WSS 3.0 environment with a huge site collection. It’s a root-site with 200 sub sites with sub sites. This is a free for all SharePoint with no boundaries. Which makes the maintenance a pain in the ass.
Someone (with to high permissions) renamed the built in field “Title” to “DayReportDate” on the root-site and published it over all sites changing all content types that inherit from Object.. which is well, all. And users on sub sites discovered this pretty quickly and changed their child content types title field back to “Title”. This caused a huge problem since when trying to rename the root-site title field back to “Title”, SharePoint would say “The column name that you entered is already in use or reserved.” even if it’s just reserved on one of the sub sites.
Everyone panicked because their title field was changed to “DayReportDate” and more than 200 sites where affected by this mistake. Having this problem for 6 months they decided that someone with SharePoint experience should take a look at the problem so the case landed on my desk. Yippie!
A problem for me was that I had no server access, so I could not create a console application (or likewise) using the SharePoint server API to correct it. And since it was WSS 3.0 there would be no PowerShell either. So I simply had to fix it on the client side.
I found two solutions.
Links are meant to be broken, at least if you move files or change file names of documents in SharePoint.
I had a customer that required links not to be broken when file name was changed or a document was moved. They also wanted to be able to create links to a specific version, current version and latest major version. The idea was by using the document context menu, users would have the option to create these URL’s.
I wrote a post about creating URL handler for document URLs, this time we will focus on how we can reuse that URL handler to create dynamic and static URLs to documents and document-versions directly from the GUI.
Microsoft has implemented a great way to reach documents by the document id, but it seems that they didn’t fully implement it’s potential into SharePoint. Therefor I would like to show you how we implemented a useful way to reach document versions by using the document id.
This implementation requires the document id feature in SharePoint 2010 enabled. It can be found under Site Collection Features.
Creating the context menu feature
Adding a new option to the context menu is quite easy, it’s all XML. Just add a new Module to your project, I called mine CustomContextMenuActions. Then, by editing the Elements.xml, add a new CustomAction like this. By using the query-string IsDlg=1 we tell SharePoint to remove stuff from the master-page that isn’t relevant to the dialog.
Description="Create a dynamic or static document url"
It would create an action like this.
I wrote a post about adding the built in document id to the document file name. Now I will show you another way to use the built in document id when referring to the documents.
Lets say we are in a big project with several baselines . And every baseline requires it’s own version of a document, but the same document. It could be that new requirements have been added along the way or maybe the architecture has changed from one to another. This might cause the document name to change for some reason and that will break the link from a previous baseline.
What if you had a link that:
- Will never break as long as the document or version is not deleted.
- Can point to the current version.
- Can point to a specific version.
- Can point to the latest major version.
Lets say that link would look something like this
Latest version -> Dynamic
Specific version -> Static, kind of
Latest major version -> Dynamic
Microsoft has provided some great functions from the Office API that we can use when we search for the document via the document id.
Creating the application page – URL handler
First of we need to create an application page that can handle the query-strings from the URL. This can be done quite easy, just map the SharePoint layouts folder to you project (I also added a new folder called customapplicationpages) and add an Application Page. In our case I added a page called getdocbyid.aspx. We don’t have to create any markup for this application page, just code behind. So basically, what we need to do is capture the id and the version and find the right document and redirect to the URL. This is how I implemented it, note that the current version of a document is not a part of the document version history.