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