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
If you have a metadata-oriented structure in you document libraries, you might want to use unique permissions for each document.
This is NOT a good choice if you use folders. It will create a huge permissions matrix.
I have implemented this at my customer and I haven’t noticed any noticeable performance issues.
Let’s say you create a choice field called “Security class” with 4 choices, “Base, low, medium, high” and you want this to control the permissions for the current document.
- Base – Base permission, keep inheritance, every one can contribute. <– Default value for the field.
- Low – Everyone can read, members can contribute, owners and created by has full control.
- Medium – Members can read, no contributors, owners and created by has full control.
- High – No readers, no contributors, Owners and created by has full control.
So basically, in your editform.aspx you have a drop-down with these 4 options.
First, create a class that will handle the permissions.
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.
I discovered that this has been done many times after we did it. Anyway, I will share my experience.
Back in 2010 I was involved in a project which consisted of creating a strict SharePoint site with meta-data oriented document storage. No folders what so ever, except for 10 document libraries. This idea wasn’t that hard to implement considering how easy it is to create static metadata in SharePoint and adding it to Content Types. How ever, if you want to put all documents in the same container, you will have to use unique file-names, otherwise files with same names will overwrite each other with new versions.
Now, how do you create a unique file name that i based on the file name which the user has entered? Well, you can always just add a custom ID or the list-item-ID in the end of the file name or you can use folders like normal people and pray that no one uploads a document with identical name.
In this case we had already decided to use SharePoint 2010’s built-in feature for generating Document-ID. By using this we will also be able to use some other features that is connected to the Document-ID, like search and the ability to create dynamic URLs (which i will get back to).
One of the requirements was that the user should never have to see their document in SharePoint without the unique ID in the file name.