Project 2010: Project Permissions
Other Users Need Access to My Projects
Consider this scenario. As a project manager you create your project and now you’re ready to let others collaborate with you and so you ask yourself “how do I let others get access to my project?” By default, users who are added as resources to the project or who have tasks in the project have some level of access to it. But, these users may only have read access to the project and what about someone who is not directly associated with work on the project? How do you change permissions so that, for example, these users can read, write and publish a project?
How to Accomplish this in Project Server 2007
In Project 2007, giving access to another user who was not directly associated with your project would have likely meant making a request to the Project Server administrator to accomplish this task for you. To give access to your project, the administrator would have likely added the project to a security category and then added the category to your user account or to a group in which you belong. This was a lot of work and as the project manager you were at the mercy of the server administrator to do this work. What this typically meant was that there was usually a lag between the time when you wanted other users to help you with your project and when they actually got access to do so.
So, how has Project Server 2010 made this better?
How to Accomplish this in Project Server 2010
In Project Server 2010, the new Project Permissions feature allows users or groups that have been granted the “Manage Basic Project Security” category permission to grant users and groups access to the projects they own. To access the Project Permissions feature do this:
1. As a user who is a member of at least the default Project Managers group, go to the Project Center.
2. Select the project you want to add, remove or modify permissions on.
3. Click on the Project Permissions button on the ribbon.
On the permissions page, if no permissions have been granted, then the ribbon and page looks like this:
Here, you click the New button and you are taken to the Edit Project Permissions page. Now suppose your goal is to allow the following:
1. All Project Managers can access your project.
2. All Project Managers can open your project using Project Professional or Project Web App (PWA).
3. All Project Managers can Save changes to your project.
4. All Project Managers have the ability to view your project in the Project Center.
Here are the options on the Edit Project Permissions page you’d select:
As you can see, you can add either users or groups to your Project Permission and in this case, you’ve added the Project Managers group. You can also enable one or a combination of seven different permissions and you’ve enabled the three that will give your users the access they need. What do these permissions do and how do things work? Let’s Talk about this.
Key Point: Project Server 2010 provides the Project Permissions feature to allow self-serve security on projects.
Project Permissions – How it Works
How do Project Permissions work and what do you need to know about them? Are there cases where they won’t give you what you want? Or, are there other things you need to consider? Let’s begin by looking at the basics of the Project Permissions feature.
Mini-Categories
At a high level, Project Permissions are like mini security categories with the differences being the following:
1. These categories can be controlled by non-security administrators (at least those in the default Project Managers group).
2. These categories cannot be controlled by server administrators nor seen by them on the Manage Categories administrative page.
3. They apply only to the given project.
4. There are only seven project level permissions you can grant access to.
5. You cannot deny any of the given permissions. You only explicitly grant access on the given permission.
For more detailed information about security categories, please see the following article:
https://msdn.microsoft.com/en-us/library/ms422445.aspx
Key Point: Project Permissions function like security categories.
The Seven Permissions
Here’s is a list of the seven available permissions along with a short description of each:
Name |
Description |
Open the project within Project Professional or Project Web App |
This gives the user or group read access to the project from either Project Professional or PWA. The assumption is that the user or group already has rights to connect from Project Professional or PWA. |
Edit and Save the project within Project Professional or Project Web App |
This gives the user or group write access (can save changes) to the project from either Project Professional or PWA. |
Edit Project Summary Fields within Project Professional or Project Web App |
This is a variation of the previous permission. This gives a user or group the ability to change the project level properties on a project and to save them, but it does not give them rights to edit the entire project. |
Publish the project within Project Professional or Project Web App |
This gives a user or group the right to publish a project. This assumes the user can also open, edit and save a project. |
View the Project Summary in the Project Center |
This gives a user or group the ability to see a project in the Project Center view. This assumes you already have permissions to a use at least one Project Center view |
View the Project Schedule Details in Project Web App |
This allows a user or group the ability to drill into a project from the Project Center so that they can see the details of the project. The assumption is that you can go to the Project Center or you know the project’s URL so that you can see Project Schedule view. |
View the Project Site |
If a workspace has been published for the project, then this permission allows the user to get to the workspace page in order to see documents, issues, risks and other items associated with the project. It does not imply that users will be able to edit any of the entities in the various lists. |
Key Point: There are seven permissions you can set for a given project.
Project Permissions Dependencies
There’s a reason why the Project Permissions are listed in the order that they are. This is because in some cases, a given permission may be reliant on the previous permission in the list. For instance, let’s say you want to allow a user the ability to publish a project. To do this, the user also needs to be able to open, edit and save the project. Thus, the project permissions you would select for your user would be “Open the project in Project Professional or Project Web App”, “Edit and Save the project within Project Professional or Project Web App” and “Publish the project within Project Professional or Project Web App”. What if you selected just the “Publish the project within Project Professional or Project Web App” permission and not the others permissions? Well, your user wouldn’t be able to open the project in order to invoke the publish command and therefore, the permission would be dormant.
Key Point: The permissions page does not enforce relationships among the permissions. You have to set any related permission a user or group may need.
Project Permissions and other Server Permissions
Because Project Permissions are category permissions, they are additive to other permissions a user or group may already have. It also means that if a user or group has been denied access on a given permission elsewhere, they will still be denied the permission no matter how you set up the Project Permissions on your project. An example of this is a user who has been denied the Save Project to Project Server global or category permission. In this case, even though you give your user the right to edit and save the project, they will still be denied the ability to do this because the deny permission overrides any explicit allow permission given elsewhere.
As another example, suppose your user has been denied access to the Project Center view. This deny will override your wish to allow your user to view the project summary in the Project Center and they will still be blocked.
Key Point: Project Permissions don’t override explicit Deny permissions set elsewhere.
Other Considerations
If you consider the various Project Permissions available, you’ll notice that many of them are “Project Manager” centric. That is, they represent tasks such as saving and publishing a project that a member of the project managers group would normally perform. What this implies is that Project Permissions work well for peers who are also have similar permissions. But, Project Permissions become less effective as a user’s permissions are reduced. Here’s an extreme example to illustrate this. You have a user who only has the Log On global permission. As a project manager, you create Project Permissions for one of your projects and you specify that this user can view the project in the Project Center. This user logs on to PWA, but they still don’t have access to the project. This is because they don’t have access to any Project Center views. Now, if this same user were a member of the team members group, then by-default, they would have what they need to see the project in the Project Center. So, what’s the lesson here? Setting Project Permissions doesn’t provide an automatic path in PWA or Project Professional to projects.
Key Point: Project Permissions are great for users or groups who are peers but are less effective for users or groups who have fewer rights.
Using Project Permissions
There are a couple of points to understand about what you may see on the Permissions page. Here’s an example of what this page may look like after you’ve created and saved several permission sets:
So how do you interpret what you see here? Well, this means that there are at least three different unique permission sets. On the first one, the Project Managers security group has been given the Open Project, and Save Project to Project Server permissions. On the second one, team members 11 – 14 have the View Project Summary in Project Center and the View Project Site permissions. On the last one, team member 5 has been given the View Project Summary in Project Center permission. When you edit and existing or create a new permission, you can add multiple users, but when you’re finished, each user and group will appear as a separate row in the list and each appears with their own permission set.
If you edit multiple users or groups, and if they don’t have the same permissions, then all permissions for those users are reset and you have to select new ones. As an example, suppose you select TM11 and TM5 from the list and click Edit. On the Edit Project Permissions page, you’ll see both users, but in the permissions section, no permissions will be selected. Before you Save, you will have to select at least one permission for these two users.
Key Point: The Permissions page shows you each individual user or group and shows the permissions for that entity. Editing users or groups with dissimilar permissions resets the permissions.
Summary
Project Permissions in Project 2010 make it so that project managers and others can easily grant users or groups the right to perform specific actions on the projects they own. This feature reduces the Project Server administrative burden and makes it much easier for project managers to manage this chore by themselves.
Comments
Anonymous
March 07, 2010
Excellent article. I wonder if you can set permissions for specific tasks in Project 2010 or Project Server 2010? When team is collaborating on a project we may spread out the responsibilities for individual tasks and we need to ensure only assigned ressource or group can edit the specific task. Any ideas?Anonymous
October 25, 2010
Any suggested best practices? For example, how can I be sure that myself as a PM have full access, but a senior consultant can edit the tasks and resources witouth being abel to see rates, costs, etc.?Anonymous
February 07, 2012
Agree with Ivan, how can I share an ms-project file but restrict access to financial info?