Bob Mixon has a good post about the security & UI in SharePoint… specifically why the development team chose their current implementation of showing users everything and telling them when they don’t have access. I for one hate the current model… if you don’t have access either disable the option or hide it… or better yet, give me the option!
[Via SharePoint Blogs]comments powered by Disqus
I read many forum posts from various individuals wondering why Microsoft implemented the SharePoint user interface without taking the current users security into consideration. This was a question of mine early last year when I first began implementing the 2003 version of SharePoint. After many discussions with Microsoft employees, SharePoint MVP’s and various users, I find there are two broad thoughts about it.
I am told by Microsoft and SharePoint MVP’s that this is “by design“. The theory being; a tool such as SPS and WSS promote content discovery, which should not exclude a user from at least knowing it exist. When a user comes across some content (or site) they do not have permission to, provide them the ability to request access. If they are not granted access, explain why. In addition to content discovery, I was told that implementing security for every element on a SharePoint page would make the UI slow and unresponsive.
The other camp describes the problem of constantly being sent e-mail requests to access a site or some content.annoying. In addition, the argument that an edit link on a toolbar should not be displayed if the user does not have the permissions to edit that particular content is strong!
It is my hope that Microsoft blends the best of both worlds into the next release of SharePoint. I personally like the idea and promote content discovery, but have situations where I would like to disable that feature. As an administrator, I would like to be able to configure whether or not permissions are taken into consideration when the user interface is rendered. Today I get around this limitation by writing custom Web Parts that display what toolbar options are rendered and what content is actually shown.
In the meantime, there is a solution!I had a conversation with Dustin Miller, of SharePoint Experts, about this topic and reviewed some options. Just to note – all of the options are painful to implement. Meaning, if you choose to take the following approach, it is not what I would consider a “no brainer”.
You could write a custom Web Part that renders a java script array of the current users permission information. This array would contain the type of content and what access permissions the user has (if any). You could then write java script to traverse through the DOM, locate toolbar options and other various types of UI elements and show/hide them based on the permissions information. As I indicated above, this is not something for the “weak hearted”. I have been successful implementing the concept and it does work. However, for me to complete the project would require writing more java script than I ever wish to.
I find that my personal development comfort level is in .NET/C#. I prefer to write custom ASPX pages and Web Parts to accomplish these types of tasks. I do have a SharePoint looking custom control that renders a tool bar that looks and feeling like what you see displayed above document libraries and lists. One day, when my schedule allows, I will rip it out and post it here.
Do you have any other approaches to solving this problem?