Windows SharePoint Services, Permissions, Links and and Adaptive Interface

  • Article

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)
    c) For each permission check/result output a block of Javascript that hides or shows the relevant element on the page.

When the page is rendered, the javascript output of the web part is executed and the offending page elements are hidden. Of course you could also just hard code this logic inside the Team Site pages, however that would not allow you to easily check a users permissions and then dynamically show or hide links.

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

Comments

  • Anonymous
    May 18, 2004
    We are going to use a variation on your option 2, basically we are creating a frontpage theme that has the styles for the elements we don't want to show having the attribute display:none;

    I like this as it's not like permanently deleting these elments from the page, and if the themes are loaded on the server a site admin can apply or remove the settings without using FrontPage at all.

    I'll write the process up at some point, currently trying to see if I can use behaviors in a frontpage theme to change the default graphics.

  • Anonymous
    May 18, 2004
    Thanks Steven, really like that suggestion!

  • Anonymous
    May 19, 2004
    We've built a utility web part that gets included in every site def we use: It simply emits a JavaScript array containing information useful for client-side processing, including the user's name, e-mail address, and a list of their groups(roles). Makes it easy, if you add in a project custom JS, to modify the UI on the fly, even removing elements from the DOM tree to "really" hide them.

  • Anonymous
    May 23, 2004
    Sounds good Justin, have you got a eval eedition of your software?

  • Anonymous
    May 27, 2004
    Being very picky I know, but there is no such thing as "WSS 2003".

    SPS 2003, Si. WSS 2003, No.

  • Anonymous
    May 27, 2004
    Thanks Mike, quite right, don't tell our marketing department! <grin>

  • Anonymous
    May 29, 2004
    Hi Daniel,

    thanks for the detailed reply, much appreciated.

    Reassuring to know others out there have faced the same problem, and developed similiar solutions.

    I imagine all these solutions could possibly one day come together to be a single fix that is publically available, as it affects so many implementations.

    Regards,
    Giles

  • Anonymous
    April 05, 2008
    PingBack from http://copyrightrenewalsblog.info/point2share-windows-sharepoint-services-permissions-links-and-and/

  • Anonymous
    June 18, 2009
    PingBack from http://barstoolsite.info/story.php?id=4281