projectified

Groups and Categories

This is something I posted over on my Microsoft blog a while back but it comes up so often that I wanted to repost it over here.

Project Server security is something that is very flexible once you get used to how it works but it can be a bit confusing when you first look at it.

Here are the basics as I explain them to my customers:

The Group

Groups contain sets of users and they define the system level permissions that those users have the rights to perform. These include: Logging in, performing certain admin functions, create a new project, create a new resource, etc..

The Category

Categories provide access to projects, resources and views. The projects and resources that the category provides access to can be specifically called out by name or they can by dynamically included based on a set of rules within the category itself. For example a category can provide access to all projects where the user is the project owner or a status manager on a task, or all the projects where the Project Owner is ‘below’ the user in the RBS structure. I refer to this set of projects and resources as the “Scope” of the category.

Categories can be shared by many groups because of the dynamic way the scopes can be defined. The dynamic options for project and resource scope are dependent on the user and their relationship (via the RBS structure) to either the owner or team members on a project or to the resources themselves. I often, for simplicity, create a role based group and then a corresponding category. It sometimes means that there are technically more categories than is absolutely required but it does make the whole security model a bit easier to follow.

 

The Group\Category Permissions

This is the part that people often overlook.

A group and a category can be ‘linked’ or joined. When this happens there is a set of permissions that sit at that joint. This set of permissions defines what the members of that group can DO with the projects and resources within the “Scope” of the category.

If you open a Group and you see the list of Categories that are associated to group there is one of these grids for each category. If you select one of the Categories associated with the group the grid pertains to THAT pairing of group and category. If you select a different category the grid changes and is now pertaining only to THAT pairing. The same is true if you open a category and select the Groups that are associated with it. The grid pertains to the pairing. It can be edited in both places but it remains the same.

Circular Relationships in the PWA Schedule Web Part

I recently found that it is possible to create circular link relationships between tasks within the PWA Schedule Webpart. Project Pro checks for things like this as you are editing but the PWA webpart only calculates and checks for things such as circular logic when you hit the Calculate button. The part that makes it more difficult to deal with is that the error message that one gets when the Calculate action finds the circular logic does not contain the ID of the task(s) involved in the link the way that Pro does.

This means that if a user goes into the schedule webpart and makes many changes, including some circular logic they will not see the error message until they hit Calculate or Save, at which point the bad link is already in place and the error does not tell them which task it is.

The solution is to open the project into Pro which will immediately let you know about the bad logic and give you the task ID.

The error you see when you save or calculate is like the one below: