none
PS2010 - "people picker" and fine-grained security RRS feed

  • Question

  • Hi folks,

    We are currently implementing Project Server 2010 and have couple of requirements that are causing us some difficulty:

    1. We need to be able to specify various people on an opportunity (proposal) that may not be users of the system.  At the moment, we have a single-line-of-text Enterprise Custom Field at the project level for each person.  The problem with this is that there is no validation – users can key anything in to these fields.  Ideally, we would like a “people picker” for these fields.  I know that the PS2010 Solution Starters include an “auto complete” web part that allows looking up of users in specified Project Server groups, but this is not useful to us because the person might not be a project server user, and so won’t be in any PS group.  We know that the person will be in Active Directory, so something like the standard SharePoint people picker would be perfect. Has anyone come across a way to achieve this?  Ideally, there should be a link from the field to the person object so that if, say, the person gets married and their name changes, the change in Active Directory would be reflected into the field in Project Server.
    2. We need to have certain Enterprise Custom Fields to be editable only be users in certain groups.  Other Enterprise Custom Fields should be editable by users in other groups.  Is there any way to implement this kind of granular security on custom fields?  Out of the box, it seems that there is an all-or-nothing security model: if you are able to edit one custom field on a project, you can edit them all.  Have any of you implemented more granular security?

    Any advice or pointers would be very welcome.

    Thanks,
    Richard

    Thursday, March 17, 2011 11:36 AM

Answers

  • In addition to Gokul's suggestions, I might add a couple of additional points:

    1) Item #1 sounds like a job for InfoPath.  I could be wrong, but I think there was a solution starter to use InfoPath to add data to Project Server Enterprise Custom Fields (ECF).  I think I saw a webinar on it the other day - but wasn't paying close attention.  That would be the initial route I would explore.

    2) Security trimming ECF is a request from a lot of organizations.  That's a bit tough, as once you access the project file, you can change any of the ECF fields.  I've played with that, and I think the easiest solution would be to extend the Project Server ECF into a SharePoint list.  Then you can control security on the SharePoint list pretty easily.  The latest post on my blog talks about a similar mechanism - although not quite the same application.  That might steer you in the right direction.


    Andrew Lavinsky [MVP] Blog: http://azlav.umtblog.com Twitter: @alavinsky
    Thursday, March 17, 2011 8:22 PM
    Moderator

All replies

  • Hi Richard,

    Here are couple of options:

    a. Could I suggest, in keeping with your plan, creating a PeoplePicker ECF (Custom field) with a lookup table containing all those users (who may not be project server users). This allows you to pick them up from a list when defining the Project Proposal itself.  This would serve the purpose of not lettign that person log-in to PWA but essentially part of the proposal (list). 

    b. I believe for editing ECF, only Administrators have full permissions to modify/change unless security settings are modified for other groups (such as PM's) that looks simillar to EPM Admin permissions.  The risk of doing this would be enabling users (ie. PM Group)  get same access as Admins.

    I hope this clears the out of the box features with ECF and Security settings with Project Server 2010.

    Best Regards,


    Gokul Rajan
    Thursday, March 17, 2011 5:13 PM
  • In addition to Gokul's suggestions, I might add a couple of additional points:

    1) Item #1 sounds like a job for InfoPath.  I could be wrong, but I think there was a solution starter to use InfoPath to add data to Project Server Enterprise Custom Fields (ECF).  I think I saw a webinar on it the other day - but wasn't paying close attention.  That would be the initial route I would explore.

    2) Security trimming ECF is a request from a lot of organizations.  That's a bit tough, as once you access the project file, you can change any of the ECF fields.  I've played with that, and I think the easiest solution would be to extend the Project Server ECF into a SharePoint list.  Then you can control security on the SharePoint list pretty easily.  The latest post on my blog talks about a similar mechanism - although not quite the same application.  That might steer you in the right direction.


    Andrew Lavinsky [MVP] Blog: http://azlav.umtblog.com Twitter: @alavinsky
    Thursday, March 17, 2011 8:22 PM
    Moderator
  • Andrew, Gokul,

    Thanks to you both for your suggestions.  For some reason, the "alert me when someone responds to this post" doesn't seem to be working for me, so I have only just seen your replies.

    It isn't going to be practical to have an ECF/Lookup for the people picker - far too big a list to maintain - but using InfoPath with a Person/Group Picker control might be the way to go.  I'll explore that option.  The other thing I was thinking was to try the SharePoint List Viewer web part from the Solution Starters, and have a custom list on a site that is available to all users in the organisation...

    Thanks Andrew for pointing me to your post about capturing the project narrative - that may be the approach I use, but I'll have to work out the security aspects of it.  I guess another complication may be around how we can do reporting against these fields that are effectively outside of Project Server's databases.

    Thanks again for your help.
    Richard

    Tuesday, March 22, 2011 9:22 AM
  • I have another post next week which walks through the security aspects of managing that list.  From a reporting standpoint, you could use PowerPivot or SSRS, I would think.  Using the technique I mentioned, each list item is flagged with the Project Unique ID, so it wouldn't be too hard to join the SharePoint list with the Project Server data.
    Andrew Lavinsky [MVP] Blog: http://azlav.umtblog.com Twitter: @alavinsky
    Wednesday, March 23, 2011 12:52 PM
    Moderator
  • Thanks Andrew - I'll look forward to your blog post.
    Thursday, March 24, 2011 10:04 AM