SharePoint permission assignment in Project Server PWA and Workspaces


Posted on 25/11/2008 by Alex Angas

Project Server has its own SharePoint security groups which almost precisely equate to the standard SharePoint groups of Read, Contribute, Design and Full Control. The TechNet article Coordinate Project Server and Windows SharePoint Services security is the official word for exactly how permissions are assigned.

Essentially just as SharePoint has its own built-in list of groups for “Read”, “Contribute”, “Design” and “Full Control”, then Project Server comes to the party with “Readers (Microsoft Office Project Server)”, “Team members (Microsoft Office Project Server)”, “Project Managers (Microsoft Office Project Server)” and “Web Administrators (Microsoft Office Project Server)”

Here is a simplified summary of the rules that explain how users get their permissions. This is without the “(Microsoft Office Project Server)” suffix but with standard SharePoint group names in brackets:

  • User that publishes the project has Project Manager (Design) permissions
  • Users assigned to tasks within the project have Team Member (Contribute) permissions
  • Users on the Resource Sheet of a project have Reader (Read) permissions
  • Users that have Manage Windows SharePoint Services permission have Web Administrator (Full Control) permission over all workspaces
  • Users that have Save Project permission have Project Manager (Design) permission over all workspaces

This looks complicated and it is. Try explaining to a project manager that access to documents in their workspace depends on who is added to the project’s Resource Sheet. It just doesn’t make sense! Then try explaining to an administrator why there is a group called “Readers (Microsoft Office Project Server)” as well as the standard SharePoint group called “Read”. It just doesn’t make sense!!

Then there’s the inflexibility of the rules themselves. There are no options – they are either on or off. And if you don’t go with MS on this one folks and uncheck the box for Workspace Permissions in Server Settings / Project Workspace Provisioning Settings, then only the Project Server service account is given access to new workspaces! This is hardly useful to the humble user needing to assign permissions who will never get their hands on this particular username and password. It just doesn’t make sense!

The bug happens when one or more of the following operations is occurring at a time:

  1. Creating a new workspace by publishing a project (queue job “WSS Workspace Create”)
  2. Resynchronising workspace permissions from Server Settings / Project Workspaces (queue job “WSS Workspace Membership Synchronisation”)
  3. Changing a user’s Project Server groups which results in changes to SharePoint permissions (queue job “User Synchronization for Project Web Access App Root Site and Project WSS Workspaces”)

Then the bug hits, permissions are only partially assigned so as this happens again and again, a user’s consistency of access disappears. The only solution is to try and resynchronise the workspace with fingers crossed that it succeeds without another SQL deadlock. But you’re completely out of luck when running a batch job that affects several workspaces such as number 3 above. The workspace it reached before everything went horribly wrong doesn’t appear to be logged!

Because of the SQL deadlock failures, the SynchronizeMembershipForPwaAppRootSite() method in the WssInterop web service has been looked at. This performs a complete resynchronisation across all workspaces, functionality that is not available through the UI. Unfortunately with testing in UAT (less powerful than production but still a three server farm), this operation was going to run for days. Also, no other sync jobs could occur at the same time or else it would be SQL deadlock again!

Bugs are the worst, but implementation is also a shocker because of the huge length of time these jobs take to run. For example, up to 7 minutes for numbers 1 or 2 above, and 15-45 minutes for number 3 depending on number of users with changed permissions. This is exacerbated as more workspaces are created (the problem seems to be more related to number of workspaces rather than number of users). The server environment where this issue is occurring is very powerful and speed should not be an issue.

We’ve looked at the problems with this feature, so what can we do about it? Well the new Project Server 2007 eventing model isn’t broken, so if you have a developer handy use that!

First, uncheck the Workspace Permissions box in Server Settings / Project Workspace Provisioning Settings. Then, have a look at the WssInterop event WssWorkspaceCreated. This fires whenever, um, a workspace is created. The initial state of a created workspace is with permission inheritance broken and the service account assigned to the workspace with Full Control.

From here, use SPWeb.EnsureUser for each user you’d like to give access to the workspace. This works by adding the user to the SPWeb if they haven’t been already. This does not give the added users any permissions to the workspace. SPWeb.EnsureUser also works with Active Directory groups, so a model where every user needs read access can be simply accomplished. Finally, use SPWeb.RoleAssignments, SPWeb.RoleDefinitions, and SPRoleAssignment.RoleDefinitionBindings to assign users the correct permissions (sorry, hopelessly glossed over but there are examples out there on how to use these).

Something else to note about a custom solution is that despite unchecking the Workspace Permissions box earlier on, Project Server’s behaviour does not change when giving access to the PWA site. It will still handle this for you according to the rules in Part 1, leaving you to configure the permissions for the workspace with custom code.

This works fine and if you are able to make use of Active Directory groups, is fast as well. Plus now that you’ve gone custom, you have all of the freedom (and traps) of flexibility and the ability to create your own permission assignment rules. Don’t forget you’ll need to invest time in creating custom administration pages to manage those as well.

So what about going forward and sticking with the product for a solution? For Project Server 14 or 2009 or 2010 I have no idea if there will be any changes to the workspace permissions functionality. If you agree that this feature needs looking at, please give feedback to the Project Server team as they do read it and listen (I’ve had great responses from Treb Gatte and Brian Smith on other issues). Hopefully bugs will be fixed and the feature improved next release!