Project Server 2010 - Team Member Group Permissions Bug

In my blog, i would like to highlight one of the issue been fixed after applying the December CU of Project Server 2010. Few weeks back i come across this issue while i was trying accessing Projects as Team Member group user. Initially i thought it was me who forgot to check an appropriate category permission but after confirming few times all the settings, my doubt became concrete when i browse through a techNet site - where more than a few users have registered a similar incident as an Issue.

To make my self more meaningful, below is the scenario:

Scenario:

• Resource is a member of Team Member group.
• Resource is only allowed to view the Project plan
• Resource is not allowed to edit any Project custom field information
• Resource is not allowed to edit Project Schedule

Following is the screen shot of the Team member group permission following the above scenario:

Result:

When user of the above mentioned group try to access the project detail from the Project Center, the user will end up with the following error.

When access project, Error.

First Solution:
For the sake of work around, if you only allow user to Edit Project Custom fields (which ideally shouldn't be allowed), it will work.

The user is now able to edit the Project summary fields, but not able to change the Project schedule.

Second Solution:

If you deny the Edit Project Summary fields and allow user to Save project to project server and publish project (ideally this shouldn't be allowed to team members) it will work: The user will not be able to edit the Project custom fields, but enable to update the Project Schedule :)

The fact of the matter is, both the above solutions are not acceptable for customers. It does not make sense that the user of the Team Member group can update Project custom field or Project Schedule or both. I have also found a comment of one of the senior moderator at techNet, and he wasnt agreed of calling it an issue and rather explained it as design behavior of new Project Server 2010. But on a contrary, i stick to my opinion of calling it a Issue, as to me no design is good if its unable to fulfill customers basic requirement.

Although the Microsoft has released a hot fix ( http://support.microsoft.com/kb/2459112/) to fix the above issue. The more good news is that MS has also released December CU for Project Server 2010 (http://support.microsoft.com/kb/2459258/) which contains this fix along with the other fixes. Applying this CU will enable Team member users to access the Project detail only by allowing them to Open Project group permission.

Read More

Project Server 2010/2007 Permission Settings

Assuming yourself at client side, finalizing your PWA configurations including Group permissions and planning to sit with the client to go through the PWA home page - and just found that the end user being part of the Project Manager group can also be able to delete any item from the custom list, able to change the web part settings, able to change the PWA theme and so on.

Now this will leave you wondering that how this is possible, and you might go through your Group/Category settings agains to verify the permissions. Actually apart from Group/Category permission, you also have to customize the PWA site permission to avoid any such situation. When you provision the Project Web App site, the default PWA site permission settings grant way too much permission to a user which in most cases are not acceptable. The groups permission settings allows user to use the PWA features, few of them are such as:

• Accessing Projects
• Accessing Resources
• Accessing Views
• Administrative settings

Now as stated above, after provisioning the PWA site, Project Server creates four levels of permissions for the PWA site:

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

Do not confuse this Project Manager group here with the Project Manager groups available in server settings of your PWA. This Project Manager group include all the users:

• who have the permission to save project OR
• permission to publish the project on project server.

which means that if you have configured your Portfolio Manager Group/Team lead group to have any one of the above permission, they will be part of this permission level. So basically we have to customize the permission level of Project Manager Group and Team Members Groups.

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 Site Permissions

    5.   On the Permissions: Project Web Access page, click Permission Levels

You should now see the Permission Levels page. You should see thirteen Permission Levels listed — the four i have described earlier, and the standard SharePoint ones (Full Control, Design, Contribute, Read, Limited Access, View Only, Approve, Manage Hierarchy, and Restricted Read).

Click on the Project Managers (Microsoft Office Project Server) permission level, and uncheck the permission as per your requirement, such as:

• Manage Lists
• Overide Checkout
• Delete items
• Manage permissions
• create subsites
• Apply theme and borders
• Manage Alerts
• Create Groups, etc.

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 not required permissions as above.

Removing these permissions prevents non-admins from altering the look, structure, or content of pages and etc. within PWA. We also prevent them from altering lists, discussion boards, and document libraries in PWA. Note that changes to these List permissions do not affect the ability to link Tasks to Workspace Items (documents, issues, deliverables, or risks); this behavior is controlled by the Create Object Links Category permission.




Read More