Creating a Private Document Library in the Project Site

Project Server contains its very own Security model. The Project Site however actually leverages off the SharePoint security model as Project Server is a SharePoint application. Certain actions such as a Project Publish event for example trigger Project Server to interpret and assign permissions of the project team in the Project site based on their individual permission set under the Project Server model.

Out of the box Project site permissions are triggered by following actions

Read Access	By adding a named Enterprise Resource to the Project schedule and the schedule has been published. The means the user would be visible under the ‘Resource Sheet’ view.
Edit Access	A named Enterprise resource is assigned to one or more tasks in the schedule and the schedule has been published. Edit access allows the user to create and edit items in lists or libraries within the project site. If using Generic resources you will need to create a dummy task in the schedule with 0% unit assignments to trigger this process.
Designer Access	This is generally provided to the project manager as the owner of the project. It extends the edit access by allowing this user to perform design type changes such as adding or modifying list columns, views and certain list or library type settings.
Full Access	Administrator access which provides Full Access to the project site.

 

This generally handles the majority of security requirements however there are situations whereby your project site requires a bit more flexibility. For example the Project Manager may require a secured area to maintain Project sensitive documentation. To achieve this requirement we can utilise the SharePoint security model but there are some rules to abide by. The following process provides instructions on how private document library can be configured and secured in a project site. Please note the same concept can be applied to any SharePoint list or library within the Project Site.

1.      Navigate to the Project site.

2.      From the ‘Site Actions’ menu select ‘New Document Library’

3.      Complete the base details. Consider turning on version control as this is a nice SharePoint feature to utilise. Click ‘Create’ to create the private document library in the Project site.

4.      Under the library tab, click ‘Library Permissions’. By default the library will inherit permissions from its parent. Since we want to secure this area and make it unique, click the ‘Stop Inheriting Permissions’ button. Click OK to confirm the change.

5.      Tick all the users you would like to remove permissions from in this library and click the ‘Remove User Permissions’ button. Ensure you leave administrator accounts and most importantly, your own account. Click ‘OK’ to confirm the change.

6.      The trick with configuring unique project permissions is to ensure the user is not associated to any of the project server permission. They are easily identified by the ‘(Microsoft Project Server)’ suffix. Let’s say a new user is granted edit (Contribute) access to the new secured document library. If you left the permission suffixed with ‘(Microsoft Project Server)’, the next time project server triggers its site synchronisation job it will note the user is a member of a Project Server monitored permission, and if the matching Project Server permissions do not provide access to that area, the permissions will be reset or removed from that user accordingly.

7.      Edit an existing user from this library by selecting the corresponding check box and click the ‘Edit User Permissions’ button.

8.      In this example we will grant Amy ‘Contribute’ access to this private documents area so Amy can edit and modify any documents within this library. Ensure we use the SharePoint equivalent and NOT the permissions with the ‘(Microsoft Project Server)’ suffix. Leaving the Project Server permission could result in a loss of permissions the next time a project site permission synchronisation job is triggered. Click OK to apply the permission change.

9.      Unique project permissions have now been applied to the new ‘Private Documents’ library within the Project Site in a way which won’t be overwritten by the Project Server Security Model.

 

Using this same technique, unique permission can be applied to any list or library within the project site. Adversely you could create a ‘Public Documents’ library which provides a more general access area. Even pure SharePoint users (Non Project Server) can be granted access to such areas of the Project Site. It is also worth mentioning this example reveals how to secure an individual document library but unique permission could also be set at an individual item level within the library or list.

The following table provides a mapping between SharePoint permissions and Project Server monitored permission within the Project Site

SharePoint Permission	Project Server Monitored Permissions	Description
Read	Readers (Microsoft Project Server)	As the name suggests, provide read access to the project site. This access is generally triggered by adding a named Enterprise Resource to the Project schedule and the schedule has been published. The means the user would be visible under the ‘Resource Sheet’ view.
Contribute	Team Members (Microsoft Project Server)	Provides edit access to the project site. A named Enterprise resource is assigned to one or more tasks in the schedule and the schedule has been published. Edit access allows the user to create and edit items in lists or libraries within the project site. If using Generic resources you will need to create a dummy task in the schedule with 0% unit assignments to trigger this permission change.
Design	Project Managers (Microsoft Project Server)	This is generally provided to the project manager as the owner of the project. It extends the edit access by allowing this user to perform design type changes such as adding or modifying list columns, views and certain list or library type settings.
Full Control	Web Administrators (Microsoft Project Server)	Administrator access which provides Full Access to the project site.

 

Even AD groups can be added and granted permission in the same way as a single user.  It is also worth mentioning SharePoint groups can also be used to maintain project site permissions.