none
Project Site Field Locking - How to restrict access, or lock specific fields RRS feed

  • Question

  • Hello,

    We have a customer who stores business case information on a SharePoint Project Site page (Environment:  Project Server and SharePoint 2013), e.g. Approved project start and end dates, allocated project funds etc.

    This BC information is entered by a PMO super user and should not be altered by end or standard Users.  What are my options here to restrict Users from editing a specific set of SP fields within a Project Site? 

    Can I use SPD workflow to lock fields, or can this be done a better way?

    Many thanks in advance.

    Wednesday, May 10, 2017 12:07 AM

All replies

  • Hi,

    Custom code could do the job, but why not simply create a sharepoint site and give access only to the relevant PMO user(s)? It would save you developing a code solution.

    Also using Project Server ideation might be a good idea to track BC in a sharepoint list and then transform them into standard projects.

    https://blogs.office.com/2012/11/05/demand-management-and-ideation-in-microsoft-project-online/


    Hope this helps,


    Guillaume Rouyre, MBA, MVP, P-Seller

    Wednesday, May 10, 2017 6:47 AM
    Moderator
  • Hello,

    Why not just break the permission inheritance on this list on each Project Site and set it so that only the PMO can edit the list but all other users and view only?

    Paul


    Paul Mather | Twitter | http://pwmather.wordpress.com | CPS | MVP | Downloads

    Wednesday, May 10, 2017 7:13 AM
    Moderator
  • Hi Guillaume,

    Unfortunately that option isn't best practice and requires a great deal of admin overheads.

    (I wish they'd be happy with this approach)

    Regards

    Nick

    Monday, May 15, 2017 3:54 AM
  • Hi Paul,

    Unfortunately that option isn't best practice and requires a great deal of admin overhead - this is my understanding, am I wrong on this?

    Regards

    Nick

    Monday, May 15, 2017 3:55 AM
  • Hi Nick,

    Why would this not be classed as best practice? I agree with the admin overhead part though - but that could be minimised. If the PMO are the ones who edit data on this one list - once the project is set up part of that process could be that the PMO edit the list permissions (a few clicks) then add the data as required? Or you look to develop a custom event handler that did the permissions on that list for you once the project site is created.

    Paul


    Paul Mather | Twitter | http://pwmather.wordpress.com | CPS | MVP | Downloads

    Monday, May 15, 2017 5:43 AM
    Moderator
  • Thanks for the reply Paul,

    In my experience (maybe not 'best practice') no client has ever wanted to manually configure permissions for each project/project site.

    Both good ideas but again in my travels (mainly government) clients want 'simple to manage, minimal overheads, minimal admin costs and zero customisation'.

    My wish list for improved Project Server functionality seems to just grow and grow!


    Thursday, May 25, 2017 11:26 AM