I was reviewing a case yesterday and just checking the behavior of SharePoint permissions in Project Web App after an upgrade from 2007 to 2010 – either in place or a 5 database – thought this might be useful information to blog about.
In 2007 in the Project Web Access site the users would be added directly to the site with SharePoint permissions based on their roles. These permission levels were identifiable by their names which would be like Project Managers (Microsoft Office Project Server). In the Project workspaces these same permission levels would be used, and the users again added directly based on their roles within the project. So this generally be a small subset of the overall user population – just those added as resources on the plan, and potentially others depending on the use of the View Project Workspace permission within categories. Here is the start of the list of permissions on the PWA site – Project workspaces will be similar although the permission levels may be different.
In 2010 in Project Web App we now use groups within the /PWA site and the users are added in to these groups rather than directly to the site. The groups are named Project Managers Group (Microsoft Project Server), Team members group (Microsoft Project Server) etc. Some individual user accounts will be present in PWA as shown below (blanked out) – these will be site collection administrators and other farm admins.
For the Project sites (formerly called workspaces) we still add the users directly, but we have new SharePoint permission levels which are named similarly to 2007, but we have dropped ‘Office’ from the product name – so they are now like Readers (Microsoft Project Server), Web Administrators (Microsoft Project Server).
If you upgraded from 2007 to 2010, either in place or 5 DB then you will retain the old permission structure – but also get the new ones too. So for example you would see all your users individually in the Project Web App permissions, as well as them belonging to the respective groups. At the Project Site level you would see the users but with both Permission Levels applied – so they might have Web Administrators )Microsoft Office Project Server), Web Administrators (Microsoft Project Server).
All of this is the expected behavior and none of this will break anything, although I admit it may look unusual having the two sets of permission levels. Also it does not leave any security issues as in 2010 if I remove someone from a Project plan then they get taken off the site with both sets of permission levels – and if I inactivate a user they are removed both at the individual level from PWA and also removed from the group that 2010 would have put them in – so all is good. If you really wanted to then you could delete the permission levels with (Microsoft Office Project Server) in the names, and also remove the individual user permissions on PWA (apart from the site collection admins of course). Worth checking that the groups contain the members you expect first just in case for some reason the sync hasn’t populated the groups yet.
Explained very well & Very informative . Thanks for sharing the article Brian.