Windows SharePoint Services, Permissions, Links and and Adaptive Interface
I started to reply to a comment from Giles in one of my previous posts and then figured it was probably worth a post on it's own. So here is the original comment from Giles:
"As a consultant, what do you tell clients looking for a collabration solution about the way all administration options are displayed to all users regardless of security profiles? Personnally, I have written a client side hack to hide all the admin options, which can be switched off if the user is an admin. "
This is one of the first comments we here from people after they have been using a Windows SharePoint Services team site. Unfortunately an "adpative" user interface, that is one that trims the options available to you based on your permissions, didn't make it in WSS 2003. That said, it has been implemented for some features in SPS 2003, for example you can't see areas you dont have permissions to and you dont see the "Site Settings" link unless you have the right permissions. In some ways this actually makes it more confusing, but bascially pure SPS functionality does trim based on your permissions, WSS functionality that is consumed within the Portal does not, for example a document library or contact list.
The first thing I would like to say here is that this is security, and because it is security this is not something that should typically be messed with. While it is common to implement work-arounds to perceived product limitation, and that most of the time these are harmless, work-arounds when it comes to security have the potential to be very far from harmless.
So with that said, if hiding links that a user does not have access to is important to you, you have a number of options, here are a couple of the more common ones.
1. Manipulate the UI via client side script.
This is probably the most common, simplest and safest approach to customising based on permissions. My favourite implementation method is as follows:
a) Create a new web part
b) In the web part perform the permissions checks you need to determine what the user can do (although this could potentially do anything)
(Should really drop some sample code up on this, stay tuned I will dig it up....)
2. Open in frontpage and delete the links.
This approach works in a number of scenarios, though is certainly not suitable in all cases. Basically this involves opening the site in Frontpage and then deleting the offending links, this of course is a "irreversible" operation (well, to the extent that you have to manual put it back in again if you decide you want it at some later date). I have commonly used this approach to remove the "Site Settings" link from Team Site horizontal navigation bars, with Administrations being given the link in their Favourites instead.
3. Implement an IIS module. I have not done one of these myself, however I worked on a project where a colleague of mine implemented one. They scare me a little because of the potential for impacting overall site performance, and are probably a little more scary from a support professionals perspective because it is server side, but they do offer and very neat, flexible and powerful option.
So, Giles, hope that answers your question, look forward to any approaches others out there may have implemented.