Delegation in Project Server 2010 is one of those features that I’ve been vaguely exposed to but have never really played with in detail. I always felt that the feature was designed for one user to cover for another user – a nice idea, but a function that I never saw a major need for (although my supported user base is starting to convince me otherwise).
Lately though I‘ve seen the feature mentioned in a different perspective – as an administrative aid. Those discussions were percolating in the back of my head until a client asked me how they could test specific security and views from various perspectives. That’s when delegation finally clicked for me. I played with it, and yes indeed, delegation is a fantastic tool to test Project Server from multiple user roles.
This functionality doesn’t quite replace setting up a couple of dummy accounts to test with, which was the typical practice with the 2007 version of the tool. As long as you stick with Project Server functionality, delegation’s pretty good. Once you start testing BI Center or PDP security though, delegation won’t work, and you’ll have to go back to use dummy accounts.
I also must point out that this is not a very original posting. In fact, when I started looking for documentation on this feature, I found this great one from Alex Burton dated way back in December 2009. So consider this post to be the blog equivalent of the digital bump in the distribution list.
This post may be a little different in that it’s written from the perspective of an administrator testing the system. My goal is not to roll delegation out to everyone in the organization, but merely to turn on just enough of it to allow the administrator to become a delegate to anyone in the resource pool.
Heather O’Cull wrote a great write up of the security settings in her post from March 2010. The key to turning on delegation is to turn on three of the four security toggles in the Project Web App Permissions:
- Manage Resource Delegates – this toggle turns on the feature and allows you to use it.
- Can Be Delegate – this allows you to become a delegate.
- Manage My Resource Delegates – this allows you to assign yourself as the delegate for another user.
Last but not least, we have the fourth security setting…
- Manage My Delegates – this security setting is not strictly required in this scenario as it allows you as administrator to assign someone else to be your delegate. You could turn it on, but if we use the principle of least permissions, I would leave this one off.
Group Security Settings
Each of those security settings has a corresponding setting in the Global Permissions section of the User Group. I would make sure that everyone but the Administrators group have these permissions checked off, i.e. a soft deny. The Administrator should have all permissions checked to “allow.”
Note that the Administrator Group:My Organization Category also has a Manage Resource Delegate option that is on by default – but off by default for the other groups.
Testing Specific Roles
Once the security has been configured, you merely have to navigate to the Personal Settings option on the Quick Launch menu.
Once there, select the option to Manage Delegates.
Save the configuration. When you wish to test the role, simply go back to Personal Settings and choose the option to Act as a Delegate.
You now see Project Server through the same perspective as the user selected in the delegation configuration screen. Click on the yellow bar to stop the delegation process and return to your normal permission level.
One of the other reasons that I wasn’t so keen on delegation when I was first introduced to it was that there didn’t appear to be much of an audit trail based on who was doing what on whose behalf. When doing research for this post, I turned up on old posting from Christophe Fiessinger where he provided a tool to capture when delegation was turned on and for which users.
Migrating from 2007? Check out Brian Smith’s blog on delegation in migrated environments.
And finally, it’s all documented on Technet.