reprinted from projectserverblogs and technet.

 

 

3 April 2008

At many of my clients, I encounter situations where the default Permission Levels created by Project Server for Project Web Access sites cause problems. Typically, everything is going along just fine when suddenly one day PWA has a different theme or the “My Tasks” or “My Timesheets” page is blank and/or throws an error. While on occasion the error is legitimate, usually it is due to an inexperienced user editing the Shared version of the page. If you haven’t encountered this issue yourself, at this point you may be wondering how this is possible… The simple answer is that for many organizations, the default Permission Levels grant too much power to non-Administrative users.

When you provision a new Project Web Access site, Project Server creates four Permission Levels (described in this technet article):

  • Web Administrators (Microsoft Office Project Server)
  • Project Managers (Microsoft Office Project Server)
  • Team Members (Microsoft Office Project Server)
  • Readers (Microsoft Office Project Server)

By default, the Project Managers (Microsoft Office Project Server) permission level has all permissions with the following exceptions:

  • Manage Permissions
  • View Usage Data
  • Create Subsites
  • Manage Web Site
  • Create Groups
  • Enumerate Permissions
  • Manage Alerts

The default Team Members (Microsoft Office Project Server) permission level has all permissions with the following exceptions:

  • Manage Lists
  • Override Check Out
  • Manage Permissions
  • View Usage Data
  • Create Subsites
  • Manage Web Site
  • Add and Customize Pages
  • Apply Themes and Borders
  • Apply Style Sheets
  • Create Groups
  • Enumerate Permissions
  • Manage Alerts

As you can see, these permissions are fairly liberal. They allow Project Managers to alter PWA’s theme and edit PWA pages and lists, among other things. For many organizations, this is much too lax.

As you may already know, these Permission Levels are not exclusive to the PWA Root site; they are also created in any Project Workspace provisioned by the server. This is how Project Server synchronizes permissions between a Project and its Workspace. For Project Workspaces, users in these Permission Levels are synced on Workspace Creation and Project Publish if the server is configured to do so. However, the Permission Levels in Project Workspaces are not inherited (by default) from the Parent Web Site (in this case, PWA). Therefore, changes we make to the PWA Root site will not affect any downstream Workspaces.

However, these roles are deleted and recreated in the Project Workspaces by the Project Workspace Membership Sync process; this is also done in the PWA site by the PWA Root Sync. This means that any changes you make to these permission levels in PWA or any Project Workspaces will be erased when the membership of that site is synchronized.


Before we get started, I want to remind you that the typical disclaimer applies. Please use caution when implementing these instructions in a production environment.

If you choose to do so, you are doing so at entirely your own risk.

I very strongly recommend that you test in your development and staging environments before applying to production, and as usual, I bear no responsibility for any issues, data loss, financial costs, or downtime you may incur from following this HowTo.

To resolve the issue, we are simply going to set the permissions of the Project Managers (Microsoft Office Project Server) and Team Members (Microsoft Office Project Server) permission levels within the PWA Root site to be equal to that of the Readers (Microsoft Office Project Server) permission level. To do this:

  1. Log in to PWA as an Administrator
  2. Expand the Site Actions menu by clicking on it
  3. Click Site Settings
  4. On the Site Settings page, under Users and Permissions, click Advanced Permissions
  5. On the Permissions: Project Web Access page, expand the Settings menu by clicking on it
  6. Click Permission Levels

You should now see the Permission Levels page. You should see ten Permission Levels listed — the four we described earlier, and the standard SharePoint ones (Full Control, Design, Contribute, Read, Limited Access, and View Only).

Click on the Project Managers (Microsoft Office Project Server) permission level, and uncheck the following:

  • Manage Lists
  • Override Check Out
  • Add Items
  • Edit Items
  • Delete Items
  • Approve Items
  • Delete Versions
  • Add and Customize Pages
  • Apply Themes and Borders
  • Apply Style Sheets
  • Browse Directories
  • Edit Personal User Information
  • Manage Personal Views
  • Add/Remove Personal Web Parts
  • Update Personal Web Parts

Click Submit, which will return you to the Permission Levels page. Now, click on the Team Members (Microsoft Office Project Server) permission level, and uncheck the following:

  • Add Items
  • Edit Items
  • Delete Items
  • Approve Items
  • Delete Versions
  • Browse Directories
  • Edit Personal User Information
  • Manage Personal Views
  • Add/Remove Personal Web Parts
  • Update Personal Web Parts

Removing these permissions prevents non-admins from altering the look, structure, or content of pages within PWA. We also prevent them from altering lists, discussion boards, and document libraries in PWA. All of the organizations I have worked with do not perform collaboration (e.g. lists, document libraries, discussion bo