none
Control access to a subset of documents in a project workspace? RRS feed

  • Question

  • We all know that MS Project controls the project workspace security.    Is it possible in a project document library to limit viewing of certain documents to specific set of team membes?  Say, only 6 people should be able to access a sub-set of docs in the project document library.  But the rest of the team can see all the others.

    How do you go about doing this?

    Thanks,
    Andy Novak, PMP, MBA
    University of North Texas System

    Thursday, January 26, 2012 6:11 PM

All replies

  • Yes, it works more or less like windows folder permissions with inheritance.  By default, your project document library inherits permissions from its parent (project) website, but by modifying the list settings on the library you can break this inheritence and set specific permissions.

    Likewise, folders within the library can be created and their permissions adjusted; you can also edit permissions on individual documents using 'Manage Permissions'.

    I would test this first in your particular setup/version if you have the automatic workspace permission sync enabled, to ensure that permissions don't get modified after a sync.  Some bugginess and sharepoint ideosyncrasies have resulted in me being locked out of my own lists before!


    Terrie T - MCTS - PMP - MBA****PMO & Project Server Admin
    Thursday, January 26, 2012 8:32 PM
  • Here's the kicker.   As the Project Server Admin, I can do that, but one of my Project Managers who published the project and is the project workspace owner, is not presented with the ability to manage permissions at any level.

    What's the deal?   Surely I don't have to do that for all users and all sites?

    Thanks,
    Andy Novak, PMP, MBA
    University of North Texas

    Friday, January 27, 2012 9:59 PM
  • The permission level named 'Project Managers (Microsoft Project Server)' do not have 'Manage Permissions' rights, unfortunately.

    OOtB only administrators have the permissions to handle security.

    It's a fairly simple hack to create an event handler that modifies this setting when a project plan is published, for instance.

    Or you could use this powershell script as a starter for your own modification - the script is used to give a domain group (consisting of a group of managers that do not have PWA accounts) access to all the project workspaces as 'Contributors':

    cls;

    $siteurl = "http://w2008s-002-vpc/pwa";
    $SPGroupName = "DomainManagers";
    $sitepermlevel = "Contribute";


    $14HiveDir = "${env:CommonProgramFiles}\Microsoft Shared\web server extensions\14\"
    cd $14HiveDir
    [void][reflection.assembly]::Loadwithpartialname("Microsoft.SharePoint") | out-null
    [void][reflection.assembly]::Loadwithpartialname("Microsoft.Office.Server") | out-null

    function get-spsite ([String]$webUrl=$(throw 'Parameter -webUrl is missing!'))
    {
        return New-Object -TypeName "Microsoft.SharePoint.SPSite" -ArgumentList "$webUrl"
    }

    function get-spweb($url)
    {
        $web = (get-spsite($url)).OpenWeb()
        $web
    }

    function AddSecGroup_SPSite([string]$url, [string]$SPGroupName, [string]$SitePermissionLevel) {
        $web = get-spweb $url;
        if($web.HasUniqueRoleAssignments -eq "True")
        {       
            $account = $web.Site.RootWeb.SiteGroups[$SPGroupName];
            $web.Site.RootWeb.Dispose();
           
            $assignment = New-Object Microsoft.SharePoint.SPRoleAssignment($account)
            $role = $web.RoleDefinitions[$SitePermissionLevel]
            $assignment.RoleDefinitionBindings.Add($role);
            $web.RoleAssignments.Add($assignment); 
           
        }
        $web.Dispose();
    }


    $pwa=get-SPSite -webUrl $siteurl;
    $SPGroupName = $pwa.Rootweb.SiteGroups[$SPGroupName];
    $pwa.Rootweb.Dispose();

    foreach ($subweb in $pwa.AllWebs) {
        if(!$subweb.IsRootWeb)
        {      
            Write-Host "Modifying $($subweb.Url)" ;
            AddSecGroup_SPSite -url $subweb.Url -SPGroupName $SPGroupName -SitePermissionLevel $sitepermlevel;
            Write-Host "Done!" ;
        }
    }   
    Write-Host "All subwebs modified!";

    $pwa.Dispose();

     

    /Lars Hammarberg, Dovre Group AB (previously known as Camako)


    //Lars Hammarberg www.camako.se Gold Certified Partner
    Friday, January 27, 2012 10:37 PM
  • Andy, there's a much simpler approach - you simply modify the permissions for the "Project Managers (Microsoft Office Project Server)" sharepoint group.  The below blog gives a good step-by-step:

    http://www.epmfaq.com/ssanderlin/project-server-2007/adjust-the-default-project-web-access-permission-levels

    You probably need to assign at least the "Manage Permissions" and "Manage List" rights to allow them to manage the doc library permissions.  The book "Microsoft Office Project Server 2007 Unleashed" has a great chapter (27) on all of this.


    Terrie T - MCTS - PMP - MBA****PMO & Project Server Admin
    Monday, January 30, 2012 2:49 PM
  • Thank you so much Teri!   I'll certainly take a look.

    -Andy

    Tuesday, January 31, 2012 3:59 PM
  • Terri,

    This sounds kind of paranoid, but there's no need to backup the project workspace, perform a full backup, etc. prior to checking this addition checkbox I , right? - nothing that unchecking the box again would cure if there were issues.  By default, PMs have "Manage Lists" for their respective project workspaces.  I'll just check "Manage Permissions" in addition to what is already there and only for now within an existing project workspace.   This article you refer to was really big on disclaimers and having no responsibilty for data loss which I can understand, but it did cause me to pause a bit (I think the article also talked about fairly substantial changes at the PWA level as well).   On the other hand, it can be unproductive to go through the backup process for every little thing.  Although I'm just making the change for now on the project workspace that currently exists, I guess making the change at the PWA level will cause that setting to be in effect as new workspaces are created and is a "bolder" move, especiallly with all the other permission removals the article talks about.  

    Thanks,
    Andy

    Tuesday, January 31, 2012 4:49 PM
  • I think a certain amount of paranoia re: Sharepoint is healthy, but I wouldn't personally take a full backup.  The worst that happens is that permissions get messed up and noone (including you) can access anything; however if all else fails you should be still be able to modify through sharepoint central admin.  It's just that the automated Project Server workspace permission sync can have unexpected results sometimes, esp if it randomly fails as it often does.  (Caveat:  I'm not a sharepoint expert!) 

     

     

     


    Terrie T - MCTS - PMP - MBA****PMO & Project Server Admin
    Tuesday, January 31, 2012 5:09 PM