Document and Folder Level Permissions
One of the most common issues people run into, especially those migrating from SharePoint Portal Server 2001, is the absence of folder level security. I have talked to many customers about this issue, and while I can't offer any solutions (It is security and this is not something to be messed with or "worked around"), I can talk around the way I think about it.
Permissions can only be set at the “Document Library” level within Windows SharePoint Services, in some ways this is actually no worse than what was available in SPS2001 (except that there is no "deny" facility on documents, but that was not all that useful anyway). Why? Well, you will hear me say this a lot (you wait, a few months and my blog will be number one for these terms), software is developed with a number of constraints, predominantly time, resources and money, unfortunately this was just one of the things that our SharePoint team was not able to accommodate.
Now, while I agree that it does appear to be a decrease in functionality, I would offer the following pieces of advice:
Try to avoid the use of “Folders”, I have found that there are very few genuine reasons for creating them, and that customer requirements can often be better met by the creation of custom metadata and custom views. There are a number of benefits to this approach including:
a. It is difficult to move documents between folders in WSS, at least via the web only interface (easier with Explorer, but what about versions and metadata?), but very simple to change the value of a custom property.
b. By assigning metadata to a document you are improving its ability to be discovered via search. The metadata value becomes part of the documents description.
To illustrate some of these benefits lets take a scenario. You have a set of files relating to a number of projects you are currently working on, Project A, B and C.
There are a number of approaches to organising this content but I will take the two most obvious ones to illustrate my point:
1. Create three “Folders” to store the documents, users then navigate to the document library they are interested in.
2. Create a custom property, a choice field, with each of the projects listed. Create three views, each filtering on this property so that you can select a view to display only the documents for each project. Modify the default view so that it displays the documents “Grouped By” the custom property.
The benefits of approach (2) are as follows:
a. To move a document between projects you simply modify the value of the metadata.
b. Search will index the “Project” property on each document, making it easier to find documents relating to a specific project.
c. Easier navigation for users. There is no “Windows Explorer” style folder tree view in WSS (at least via the web interface) so navigating down multiple levels of folders requires many clicks.
This approach has been successful with a number customers I have worked with, in one case reducing a complex 5-level deep document hierarchy to just 7 individual document libraries, four of which have folders only one level deep. This has made it much simpler for users while enriching the content itself by the smarter application of metadata.
Finally, to be clear, I’m not saying never use folders, sometimes they make sense, mostly because it is a paradigm users are familiar with, but I am saying spend time working out if there is a better way to do it given the capabilities of SharePoint.