HOW TO: Grant Project Manager’s privileges in TFS but without outright granting Project Administrator privileges
In a recent customer situation, there was the need to give a few members of the team “Project Administrator/Project Manager” kind-of/sort-of privileges. However there was a twist to it. The TFS Administrators who were managing the instance did not want the resulting set of Project Managers to have the privilege to “DELETE” the Team Project itself.
Project Administrator privileges usually mean the members of this group are given “Edit Project Level Information”.
Project-level permissions
Project-level permissions are specific to a single project's users and groups. You can set these permissions by choosing the project in Team Explorer, choosing Settings, and then choosing Security, or by opening Team Web Access in administration mode, navigating to the project, and then choosing the Security tab. You can also set these permissions by using the TFSSecurity command-line tool.
Permission Name |
Name at Command Line |
Description |
Create test runs |
PUBLISH_TEST_RESULTS |
Users who have this permission can add and remove test results and add or modify test runs for the team project. |
Delete team project |
DELETE |
Users who have this permission can delete the project for which they have this permission from Team Foundation Server. |
Delete test runs |
DELETE_TEST_RESULTS |
Users who have this permission can delete a scheduled test for this team project. |
Edit project-level information |
GENERIC_WRITE |
Users who have this permission can edit project-level permissions for users and groups on Team Foundation Server. |
Manage test configurations |
MANAGE_TEST_CONFIGURATIONS |
Users who have this permission can create and delete test configurations for this team project. |
Manage test environments |
MANAGE_TEST_ENVIRONMENTS |
Users who have this permission can create and delete test environments for this team project. |
View project-level information |
GENERIC_READ |
Users who have this permission can view project-level group membership and the permissions of those project users. |
View test runs |
VIEW_TEST_RESULTS |
Users who have this permission can view test plans in this node. |
So what happens when users have this privilege? They could then go and allow themselves the privilege to “DELETE” a Team Project itself.
While Project Administrators might need to go and DELETE a Team Project, the Project Managers who usually assign work and track the work through WITs need not and should not have to go and DELETE the Team Project itself. That is a major decision.
So we are left with a situation, where the Project Managers should only be given permissions to edit and add iterations and areas, but not allow them to DELETE the team Project itself.
So the obvious choice is set the “Edit Project Level Information” to deny for these groups. However this results in the following situation.
“Edit Project_Level Information” permission can be set as denied and this will prevent any of the PMs from altering the permissions and allowing themselves to delete the project. Good – right? It turns out NO.
The result will be thePM team will lose the ability to manage their project as they also need to edit team members, add sprints, areas and iterations etc.,. etc. All these get turned OFF when “Edit Project Level Information” is set to “DENY”. So how do we give PMs the necessary privileges, but *NOT* too much that they could end up with the privilege to even “DELETE”-ing the Team Project itself?. The following is a workaround for this situation.
The Workaround in TFS 2013, for this is as follows:
- For the group in question, do not set the “Edit Project Level Information” privilege. ie it should be at “NOT SET”.
- Then login as a Project Administrator and do the following. [You might have to do this only one time]
2.[a] Open up the Areas and Right Mouse on area and grant the perms as shown below and SAVE. (Do the same for Iterations Tab also).
2.[b] I have shown this for the contributor group, but in your case you will do this for your specific group (or let’s call it the PM Group).
3. One you do this, any user in your PM group will be able to make changes to the AREAS and ITERATIONS node, but not able to delete the Team Projects or do other type of Project Admin activities.
It is possible to do 2 (a) by using TFSSECURITY command line