Článek
07/22/2014

Plan groups, categories, and RBS in Project Server 2010

Applies to: Project Server 2010

Topic Last Modified: 2011-11-22

Microsoft Project Server 2010 security is based on users, groups, and categories. This article addresses planning for groups and categories in your Project Server deployment.

In this article:

Permissions
Groups
Categories
Security templates
Resource Breakdown Structure

Included within this article is a series of video demonstrations illustrating and further describing the concepts associated with permissions, groups, categories, and RBS. Links to the videos are included in each section below. We recommend that you view the videos in the order of presentation in this article, as each video builds on the concepts discussed in previous videos.

Note

These videos were created using Microsoft Office Project Server 2007. Though there have been some changes in Project Server 2010, the basic functionality around how Project Server security works remains the same.

Permissions

This video demonstrates how permissions work.

Watch the video (https://go.microsoft.com/fwlink/p/?LinkID=168549). To download a copy of the file, right-click the link, and then click Save Target As.

A permission is the authority to perform a specific action within the context of Project Server. You can Allow, Deny, or not configure each permission in Project Server. For example, the Change Password permission can be allowed or denied for any given user or group. There are two types of permissions in Project Server:

Global Permissions grant users and groups the ability to perform actions throughout an instance of Microsoft Project Web App (PWA). Global Permissions are assigned on a user or group level.
Category Permissions grant users and groups the ability to perform actions on specific projects and resources. Category Permissions are assigned on a category level.

Permissions can be set in a number of different places within the Project Server 2010 administration menu. You can allow or deny permissions by selecting the check boxes in the Allow and Deny columns. If neither the Allow nor the Deny check boxes are selected, the default state is Not Allow. The Not Allow state does not prevent users from accessing the feature associated with the permission if they are granted permission in some other way. For example, a user might belong to one group for which permission is not configured (Not Allowed), but might be granted permission by means of membership in a group for which the permission is allowed. However, if the permission is explicitly denied anywhere, permission is denied everywhere for a particular user or group.

You can configure all Project Server 2010 permissions from the Project Web App Server Settings page. Permissions can be configured in the following ways:

Allow Enables users or group members to perform the actions associated with the permission.
Deny Prevents a user or group from performing the actions associated with the permission. Use caution when denying permissions. Note that if a user is denied a specific permission, the deny setting supersedes any Allow settings that might apply to other groups to which the user belongs. No permissions are set to Deny by default.
Not Allow If you select neither Allow nor Deny for a permission, the default state is Not Allow. If a user belongs to more than one group, and a permission is set to Not Allow for one group and is set to Allow (but not Deny) for another group, then the user is allowed to perform the actions associated with the permission.

It is important to consider when you are configuring a permission to Deny that the Deny setting supersedes any Allow settings that apply to the user for that permission by means of other group memberships. Limiting your use of the Deny setting can simplify permissions management for large groups of users.

Note

The Deny setting enables you to deny access to functionality, because this setting overrides the Allow setting. Therefore, use caution when selecting the Deny check box. Select the Deny check box to prevent a user from outside the organization from accessing Project Server security objects or to deny functionality to a user or group).

For organizations that include a large number of users, assigning and administering permissions on an individual basis can be an overwhelming task. You can use groups to assign permissions to multiple users with a single action. Create the groups and define the set of permissions to associate with the groups as part of your initial Project Server 2010 deployment planning process, before you assign users to groups and groups to categories. After you define groups, the permissions associated with the groups, and group memberships, the day-to-day administration of users, groups, and categories involves adding users to or removing users from security groups. This helps to reduce the volume of day-to-day administrative tasks required, and can simplify troubleshooting permissions issues.

Note

For a complete list of Project Web App global permissions, see Project Server 2010 global permissions, and for category permissions, see Project Server 2010 category permissions.

Groups

This video demonstrates how groups work.

Watch the video (https://go.microsoft.com/fwlink/p/?LinkID=168587). To download a copy of the file, right-click the link, and then click Save Target As.

Groups contain sets of users who have similar functionality needs. For example, every project manager in a particular division within your organization may need the same set of Project Server permissions, while executives or resource managers might have different needs.

Define your groups by identifying common needs based on the areas of Project Server 2010 to which users in your organization need access. After you define your groups, you can add users to the groups and grant permissions to the groups; permissions assigned to groups apply to all of the users that the group contains. Using groups to control Project Server 2010 permissions simplifies security administration in Project Server. Group memberships can change frequently, but the access requirements for groups change infrequently.

Note

Group membership consists of users only. Groups cannot contain other groups.

Users can belong to multiple groups according to their role in the organization and their access requirements. The following groups are created by default when Project Server 2010 is installed, each of which is assigned a set of predefined categories and permissions:

Group	Description
Administrators	Users have all global permissions as well as all category permissions via the My Organization category. This allows them complete access to everything on Project Server.
Executives	Users have permissions to view project and Project Server data. This group is intended for high-level users who need visibility into projects but are not themselves assigned project tasks.
Portfolio Managers	Users have assorted project-creation and team-building permissions. This group is intended for high-level managers of groups of projects.
Project Managers	Users have most global and category-level project permissions and limited resource permissions. This group is intended for users who maintain project schedules on a daily basis.
Resource Managers	Users have most global and category-level resource permissions. This group is intended for users who manage and assign resources and edit resource data.
Team Leads	Users have limited permissions around task creation and status reports. This group is intended for people in a lead capacity who do not have regular assignments on a project.
Team Members	Users have general permissions for using PWA, but limited project-level permissions. This group is intended to give everyone basic access to PWA. All new users are added to the Team Members group automatically.

Administrators usually assign permissions by adding a user account to one of the built-in groups or by creating a new group and assigning specific permissions to that group.

Note

For a complete list of Project Web App global permissions, see Project Server 2010 global permissions, and for category permissions, see Project Server 2010 category permissions.

Category	Description
My Direct Reports	Allows users permission to approve timesheets for their direct descendants in RBS. This category is intended for managers who need the ability to approve timesheets.
My Organization	Contains all projects and resources and allows various levels of category permissions depending on associated group management. It also provides full access to all views. This category is intended to allow users to have visibility into everything on the Project Web App instance.
My Projects	Filtered to allow category permissions to users who own projects or are status managers on a project, are assigned as a resource to a project, or whose descendants in RBS are assigned to a project. This category is intended to allow users to have visibility into all project with which they or their descendants in RBS are associated.
My Resources	Allows most resource-level category permissions, filtered on resources who are descendants of the user in RBS. This category is intended to allow users to manage their resources as delineated in the RBS structure.
My Tasks	Allows users to see projects to which they are assigned. This category is associated with the Team Members group and is intended for everyone to have visibility into the projects to which they are assigned.

Security templates

Security templates are predefined sets of permissions. Use security templates to simplify the process of granting permissions to groups of users who need access to the same data. Each Project Web App instance includes the following default security templates:

Administrator
Executive
Portfolio manager
Project manager
Proposal reviewer
Resource manager
Team lead
Team member

Security templates provide a means for you to quickly apply or reset predefined permission profiles to new or existing users, groups, and categories. By applying security templates, you can easily standardize the permissions that you assign according to users' role in the organization. Several predefined security templates are created by default when Project Server is installed. These align with the predefined groups. You can customize these security templates and create new security templates according to your needs.

Note

When you change the settings for a security template, the changes are not automatically applied to the users and groups that the template was applied to.

Creating custom security templates requires planning. You must first identify the common Project Server 2010 usage patterns in your organization that are not reflected in the default Project Server 2010 security templates. This helps you to identify your requirements for custom security templates. Then, determine the permissions that the users who share the common Project Server 2010 usage patterns require. This defines the security template. Next, determine the set of projects, resources, views, and so on, that the users and groups require access to; this defines the security category. Create the custom security template and apply it to the group of users that share common usage patterns.

Resource Breakdown Structure

This video demonstrates of how RBS works.

Watch the video (https://go.microsoft.com/fwlink/p/?LinkID=168589). To download a copy of the file, right-click the link, and then click Save Target As.

The Resource Breakdown Structure (RBS) is a hierarchical security structure typically based on the management reporting structure of your organization, although it can also be structured in other ways. The RBS can be an important element in your Project Server security model when it is used to define the reporting relationships among users and projects in your organization. When you specify an RBS value for each Project Server user, you can take advantage of the dynamic security options that can be defined for each security category.

The RBS structure is defined by adding values to the RBS custom lookup table that is built in to Project Server 2010. Once you define the structure, you can assign RBS values to individual users by setting the RBS property in the user's account settings page.

Once the RBS is configured, Categories can use RBS codes to dynamically determine which projects and resources particular users can view or access. The following tables list the security options that use RBS that are available in each Category.

Project options

Option	Description
The user is the Project Owner or the User is the Status Manager on assignments within that project	Users with permissions in the category where this option is selected can see projects on which they are a Project Owner or a Status Manager
The user is on that project’s Project Team	Users with permissions in the category where this option is selected can see projects on which they are a resource
The Project Owner is a descendant of the User via RBS	Users with permissions in the category where this option is selected can see projects owned by their descendants in the RBS
A resource on the project's Project Team is a descendant of the User via RBS	Users with permissions in the category where this option is selected can see projects on which their descendants in the RBS are a resource
The Project Owner has the same RBS value as the User	Users with permissions in the category where this option is selected can see projects owned by other users with the same RBS value

Note

The first two options (The user is the Project Owner or the User is the Status Manager on assignments within that project and The User is on that project’s Project Team) are not related to the RBS, but they do offer a similar method of filtering which projects are visible to a user.

Resource options

Option	Description
The User is the resource	Users with permissions in the category where this option is selected can see themselves as a resource
They are members of a Project Team on a project owned by the User	Users with permissions in the category where this option is selected can see resources assigned to projects that they own
They are descendants of the User via RBS	Users with permissions in the category where this option is selected can see their descendants in the RBS
They are direct descendants of the User via RBS	Users with permissions in the category where this option is selected can see their direct descendants in the RBS
They have the same RBS value as the user	Users with permissions in the category where this option is selected can see other users with the same RBS value

Note

The first two options (The User is the resource and They are members of a Project Team on a project owned by the User) are not related to the RBS, but they do offer a similar method of filtering which resources are visible to a user.

The options in the tables above can be configured when you create or modify a Category. For more information, see Manage categories in Project Server 2010.

Sdílet prostřednictvím

Plan groups, categories, and RBS in Project Server 2010

Permissions

Groups

Categories

Security templates

Resource Breakdown Structure

Project options

Resource options

See Also

Concepts

Other Resources

Další materiály