Forum Discussion
PWA: Group/Category & Project Permissions -in relation to- SharePoint: Read vs Edit Access
tayram -- I think you are going down the wrong road asking your PMs to use the Project Permissions button to set special permissions for every project. Project permissions should be controlled almost entirely by Groups and Categories in Project Web App. Your application administrator has control over Groups and Categories, by the way. Also, if your organization is not doing so already, your Project Online system should be set up in Project Permissions mode rather than SharePoint Permissions mode, which will give your organization greater control over "who can do what" within the system.
If you are using Project Permissions mode, then there are basically three security Groups that will give your people the access that they need (or pretty close to that anyway):
- The Project Managers group gives each project manager Read/Write access to his/her own projects. It also gives the PM access in the Project Site to create and edit Risks and Issues, as well as to upload and edit documents.
- The Team Members group gives each team member access to view their tasks in only the projects to which they are assigned tasks (so that they can report progress on either the Tasks page or Timesheet page in PWA). Members of this group can also create and edit Risks and Issues, as well as being able to upload and edit documents.
- The Portfolio Viewers group can view information about EVERY project in your system and EVERY resource in your system, but they CANNOT change anything. They can also view the Project Site for EVERY project, but they can only VIEW items such as Risks, Issues, and documents, but they CANNOT edit any of them.
So, based on the above, I think your organization could nicely solve your security needs using the default Groups in PWA, adding each user to the appropriate Group. Your app admin might need to "tweak" the permissions in the Group a bit to make things work correctly.
Also, to get things to work correctly for the third group, which you describe as the Superintendents group, each of them would need to be added to the project team of every project. They do not need to be assigned to any tasks in the project, but they do need to be a part of the project team. This will give them the Read/Write permissions they need in the Project Site. Members of the second group, which you describe as the Foreman group, would need to be added to the Portfolio Viewers group, which would give them Read/Only access to the Project Sites, where they could view all Risks, Issues, and Documents, but they would not be able to edit anything.
In addition, if you follow my advice above, your PMs would need to REMOVE all of the special permissions they have set on each of their projects so that the permissions will be totally control by Groups and Categories. Hope this helps.
Dear Guru Dale_HowardMVP , thanks for your wisdom on this question, I have a supplementary ask around the same topic.
We have recently unpicked an overly complex security regime, 29 different groups, not quite so many categories and in some cases users in a large number of groups, record being 19 out of 29 possible.
i have been banging the drum to promote implicit permissions against projects through groups rather than explicit access through the options permitted by Basic Project Permissions.
Is it fair to say that explicit permissions impose more of an overhead on determining what users can see and do compare to implicit permissions arising from group membership? Our old security regime appeared to be placing a heavy demand on the server in terms of navigating the myriad permutations arising from so many security groups.
As part of our transition some users are not seeing what they used to see, which is good as it indicates that explicit permissions were not being employed, however users are tempted to use Project Permissions and granting explicit permissions to overcome this challenge rather than running with the security model as it is designed to work. We are looking at disabling Basic Project Security for the majority of our new groups as a result.
- Dominic_M10 --
Based on your description of your current security model, I suspect that what you have created is simply too complex to work reliably. It surely must be an app admin's worst nightmare. But if your PMs start adding special permissions for their projects, that will only make matters worse. My recommendation would be to do your best to reduce the number of security Groups and Categories instead. Since I cannot see your Project Online instance, I cannot advise you how to accomplish this, but I think that would be the better way to move forward. Hope this helps.- Hi Dale - thanks for the swift response. We made a change to the security model and now only have 7 security groups, I have recommended that we remove Basic Project Security permissions from users as to allow this to persist undermines the intent in simplifying the security model we now have. I will let you know if this argument wins the day.
