1,804 articles and 14,735 comments as of Sunday, February 20th, 2011

EndUserSharePoint has combined resources with NothingButSharePoint.com. You can now find End User (Mark Miller), Developer (Jeremy Thake) and IT Pro SharePoint (Joel Oleson) content all in one place!

This site is a historical archive and is no longer being updated. Please update your favorites, bookmarks and RSS feeds.

NothingButSharePoint.com
Tuesday, December 23, 2008

Security Trimming a List View

Here’s a question that comes up quite a bit. This time, it was on Stump the Panel:

Does anyone know how I can use one SharePoint List but have different site users only access specific views (kinda like security trimming views) The scenario is I am working with some lawyers who should only access data on the list they are responsible for and shouldn’t see the data the other lawyers are responsible for. I want to only maintain one list so that its easy for me to update just the one list.

Response from Paul Grenier, Moderator of Stump the Panel:

Perfect reason to use folders. Folders can have their own permissions. You can break inheritance and give every object in them the same permissions. This allows you to group things in a list or library by permission. Works great for things like a library of personal expense reports.

 

Please Join the Discussion

11 Responses to “Security Trimming a List View”
  1. Tiffany Maddux says:

    My department recently created something similar to this. Basically, I have a form library with a template used for a certain type of request. We created a new page with the form embedded, and another page with a “my documents” web part. Once we removed the tollbar, that allows them to only see the view I want them to see…the my documents. Then I created a separate page that only the people in accounting have access to, which contains direct links to the list pages where they can adjust the views as needed. Another page allows managers to see what requests are pending their approval just by restricting access to the pages. Since the list is shown in web-part format with no way to change the view, you can control what they see, and all of the updates still go to the same list.

  2. AutoSponge says:

    @Tiffany,

    Remember that hiding specific views from users does not secure the content. For instance, log in as an admin and grab a document from your “restricted” view. Then, log in as a test user (standard permissions). Paste that url and see if you get a document.

    If you got a document, then you know your users can manipulate the URL string or use web services to retrieve data they should not see. Instead, use permissions around the objects themselves instead of the views.

  3. Tiffany Maddux says:

    Well I guess I use all of the above because I also use Nintex Workflow, and you can use that to restrict permissions on a per-item level within a workflow. As an example, a person comes to my finance page and they see two links on the side. One is “my adjustment requests” and the other is “new adjustment request”. From either one of those, they can’t access anyone else’s requests. They don’t have rights to the accounting page, even if they have the direct url. They would have to have a direct url to a different view or a specific item in order to access them, and since the workflow restricts their access once a new item is created, they would get an error message if they tried to use an item url they are not supposed to have access to. Fortunately, most of the people in our company don’t know how to use any other method to get to this information. I guess it depends somewhat, too, on the technological competencies of the other people involved. So far, no one has accessed items not belonging to them (or their team in the case of the managers) except the person who performs the adjustments, myself and the IT manager who has been helping me learn the more intricate details and processes for SharePoint.

  4. AutoSponge says:

    Tiffany,

    “They would have to have a direct url to a different view or a specific item in order to access them…” People pass URLs around in email all the time. It may not be a problem within your company but if you ever invite contractors or vendors to log in, you don’t know them or their tech-savvy. Best practice: lock down the item with permissions or an ISA server, not the view.

  5. Gutek says:

    There is an easy way but needs dev work.

    Take a look at this code:
    public class Class1 : ViewSelectorMenu
    {
    protected override void AddMenuItems()
    {
    base.AddMenuItems();

    List controlsToRemove = new List();

    foreach (Control c in base.MenuTemplateControl.Controls)
    {
    if (c is MenuItemTemplate)
    {
    MenuItemTemplate menuItem = c as MenuItemTemplate;
    string url = menuItem.ClientOnClickNavigateUrl;

    url = url.Substring(0, url.IndexOf(”?”));

    if (!this.DoseUserHavePermission(SPContext.Current.Web.GetViewFromUrl(url)))
    {
    controlsToRemove.Add(c);
    }
    }
    }

    foreach (Control control in controlsToRemove)
    {
    base.MenuTemplateControl.Controls.Remove(control);
    }
    }

    private bool DoseUserHavePermission(SPView view)
    {
    if (view.Title == “All view”)
    {
    return false;
    }
    else
    {
    return true;
    }
    }
    }

    this will prohibit users for viewing All Items. You can write a handle to transfer user to diffrent location. IMHO you could create a list with default views for specific accounts/groups and transfer user to the VIEW specified in that list.

    As for the code. Build it, sign it, add to GAC, add SafeControl change DefaultTemplate.ascx to register your tag prefix plus change <SharePoint:ViewSelectorMenu to your tag.

    I was using this solution to add Security Permissions to Views in WSS 3.0.

    hope this helps

    Cheers,
    Jakub G

  6. Jakub – Youch… what the hell is THAT?

    “Build it, sign it, add to GAC, add SafeControl change DefaultTemplate.ascx.”

    It sounds like the cat just threw up. — Mark

  7. Gutek says:

    Sorry Mark, I was in a rush, should postpone the post.

    Some time ago, client asked me to develop solution for managing List Views on WSS. After some time of digging I found control named ViewSelectorMenu which is responsible for generating items in dropdown View selector.
    By overriding the control I was able to provide functionality requested by client. To use control in CONTROLTEMPLATES I’ve created a strong named assembly which need to be added to GAC. Then I overridden all CONTROLTEMPLATES that use ViewSelectorMenu, to use my selector. To enable code to run successfully I’ve added a SafeControl to Web.Config.

    My code was extended by page which enables user to specify who should be able to access specific View on specific List, and what View is default for the user.

    Hope this explain my “moaning” ;)

    Cheers,
    Jakub G

  8. Jakub – Thanks for the clarification… I think. :-) — Mark

  9. sandhya says:

    hi Jakub ,

    can you kindly explain in detail to modify/overridden control templates in sharepoint site.

  10. Rupali says:

    Hi Jakub,

    Really helpful post.
    Using this technique i can remove All items link from the Views Drop down list.
    Although end user can still type in the AllItems.aspx url to view the content. How can we
    implement the security on this particular view?

    Thanks and Looking Forward,
    Rupali K.

  11. Jakub says:

    @Rupali,

    You can do it by adding Delegate Control to SharePoint. and implementing custom “security” for views in the same way as you decide if you want to show a view i view selector.

    @sandhya

    here you have an example how to do it with list field iterator – same apply to “view selecotr”: http://msdn.microsoft.com/en-us/library/aa543922(v=office.12).aspx


Notify me of comments to this article:


Speak and you will be heard.

We check comments hourly.
If you want a pic to show with your comment, go get a gravatar!