Project 2010: Introducing Delegates

In Microsoft® Office® Project Server 2007, the timesheet surrogate feature exists to allow one timesheet user to give the management of their timesheet to another user — send updates and so forth. This is great for timesheets, but there are many other parts of Project Web App where you may want to delegate your duties to another user or users but you can’t because a delegation feature doesn’t exist. Based on this need, the delegates feature was born in Microsoft Project Server 2010. This feature simply allows one user to act as another user, no matter the permission level difference of the one user compared to the other. As an example, a team member can be a delegate for an administrator which means that when the team member becomes the delegate, they have all privileges that the administrator has.

Let’s begin by talking about the security settings that control the delegates feature. Next, we’ll talk about how you create and administer delegates. After that, we’ll talk about delegates from a reporting and programming standpoint and finally we’ll talk about a few things you need to consider.

The Delegates Security Settings

There are a number of security permissions that control whether or not the delegates feature is enabled, whether or not a given user can be a delegate or act as a delegate and who has permission to create delegates. By default, the delegates feature is turned on globally, but the feature has not been enabled for any user or group except for administrators. Therefore, in order for the "ordinary" user to participate in delegation, you need to enable it for the various groups or users that you wish. Let’s first look at the Project Web App Global Permissions.

Here in the Resource section, you can see the following permissions:

· Manage My Resource Delegates   Allows a user to set up delegates for other users.

· Manage My Delegates   Allows a user to create a delegate for themselves, but relies on someone else to pair up the delegation to another user who will do the work.

· Can be Delegate   If a delegate has been created, it allows the user to go to the “Act as a Delegate” page and act for another user.

· Manage Resource Delegates   Turns on the delegates feature.

At the user or group security level, similar global permissions can be set. As mentioned earlier, except for the administrators group, all others do not have the ability to create and become delegates.

There’s also a category permission you need to be aware of. The category permission, found in the <section name> is called “Manage Resource Delegations”.

Note: By default, in the Administrators group for the My Organization category, this permission is enabled if you have a brand-new Project Server 2010 site and disabled for upgraded sites. What this means is that for upgraded sites by-default and by-design the delegates feature does not work.

So how does all of this work? Actually, it’s quite simple. Once you become a delegate, Project Server 2010 authorizes you to connect to the server but then switches your context so that you now are working as the user you’re the delegate for. Let’s walk through the setup of a delegate so that you can see what needs to be done.

Delegate Setup

Now that you have the security settings set up, it’s time to create your delegates and to act as a delegate. Let’s suppose you manage resource Mary, and Mary has told you she is going to be out of the office for two weeks. You also know she has time that needs to be reported while she’s gone. There are two ways to handle establishing the delegate. If policy permits, Mary can set up her own delegate for you or if not, you as her manager can set this this delegate. In our example, let’s assume you’re going to manage Mary’s work for the two-week period — you can’t find another team member to do this for you – and so you’re going to setup the delegate. To do this, you go to Personal Settings and click Manage Delegates (if you have the Manage My Resource Delegates permission, you can find the Manage Delegates option on the Server Settings page).

Next, you go to the ribbon and click New.

Now you can set the period for the delegation and also the fact that you’ll be the delegate for Mary:

Once the delegation is created, and as long as the current date is within the delegation period, you are now able to work on behalf of Mary. To start working as Mary, go to Personal Settings and click Act as a Delegate. Here you can see that the delegate isn’t active though your delegate is available:

You select the delegate and click the Start Delegate Session button. At this point, you are now working as Mary and you see the same UI, tasks, timesheets and other things that Mary would see. As well, you have the same permissions as Mary. Thus, if you started out as a Project Manager and Mary is a team member, while working as Mary, you have Team Member privileges. To help alert you that you are working as someone else, all Project Web App (PWA) pages are branded with a status bar as shown below.

To switch back to your account so that you are no longer a delegate, you can click the status bar where is says “Click here” or go to Personal Settings – Act as a Delegate. Here, you simply click the Stop Delegate Session button on the ribbon.

Working with Delegates

To help you find the delegations that you own or manage, filtering can be applied. On the Manage Delegations page, click Filters on the ribbon to see something like this:

In this picture, you can see that you the manager have two different periods when you may act as Mary.

Reporting and Programming

There is no reporting available within PWA to show you, for example, when a user started and stopped a delegate session. The Unified Logging Service (ULS) log does, however, have entries to show you this sort of detail. For instance the following ULS log entries show the beginning and ending point for a delegation:

3/01/2010 09:18:34.80 w3wp.exe (0x0A04)0x1374 Project Server      General 5z1a Medium PWA:https://pserver/pwa, ServiceApp:PSERVER_ProjectServiceApplication, User:DOMAIN\user, PSI: PWA.UserDelegationActivateDelegationCalling ActivateDelegation for delegationUid 77a5b19b-2b67-4b3c-8b49-c191994ac2df.   

3/01/2010 09:40:34.98 w3wp.exe (0x0A04)0x1374 Project Server General 5z1c Medium PWA:https://pserver/pwa, ServiceApp:PSERVER_ProjectServiceApplication, User:DOMAIN\user, PSI: PWA.UserDelegationDeactivateDelegationCalling DeactivateDelegation for userUid a0672aff-c177-4908-b190-d9e24076f3ea.        

In many organizations that enable delegates, you will want to be able to tell what a user has done while acting as a delegate. Though Project Server 2010 does not have built-in auditing, you can consider using Project Server’s built-in events to help you with this. Project Server 2010 has added ten new UserDelegation events you can use to determine when a delegate session is Activated, Activating, Changed, Changing, Created, Creating, Deactivated, Deactivating, Deleted and Deleting. You may find ways to use these events as well as other events to meet your needs.

Notes and Things to Consider

Here are some things to consider about delegations.

1. Be careful about security elevation. Delegations work well for peers (those who have similar permissions) and from “managers” to “subordinates. But, you should probably avoid having someone like a team member act as a delegate for a manager, for example. You should also avoid having users act as administrators. If a user isn’t already an administrator but needs to act as one, you should probably consider just making them an administrator.

2. When you are acting as a delegate, you cannot manage delegates. This prevents, for example, users who don’t have permissions to create delegates from doing so while acting as another user who has permissions to do so.

3. Not all PWA functions work with delegation. Here’s a short list of things that may not function properly while you are a delegate for another user:

a. Issues, Risks, going to Project workspaces. When you navigate to a project’s workspace, you are using your security context and not the delegated user’s context. If prior to activating the delegate session you have access to the project workspace, you will be able to do so while acting as a delegate. But, the delegate session does not grant you permissions to the workspace.

b. Project Detail Pages. This is the same thing as point ‘a’. Essentially, whenever you leave the realm of Project Server 2010 pages and you’re in SharePoint 2010 pages, the delegation is not in effect.

c. Project Professional. The delegate session does not apply to Project Professional. Thus, if you are a team member prior to the delegate session and now you’re acting as a project manager, you will still be unable to use Project Professional to work with projects.

4. As noted earlier, if you upgrade from a previous version, delegates don’t work by-default even for the Administrators group. You will need to add the “Manage Resource Delegates” permission to a category (such as My Organization) that’s been placed on a group or user (preferably group).

5. In Project Server 2007, timesheets surrogates are used to delegate timesheets from one user to another. Surrogates have been removed from PWA 2010 and delegates is the replacement.

Comments

• Anonymous
  November 14, 2011
  Hi, I went through my PWA2010 and adjusted the group permissions, but I'm still having issues creating a surrogate timesheet.  Could you please provide some guidance in creating one.  Thanks