User & Group Permissions for Workspace Access

[Steven Douglass]

Environment: Project Pro 2007, Project Server 2007, WSS 3.0

I'm having difficulty understanding how to assign permissions for users.

All users that I want to give access to Project Server & WSS are sync'ed
with AD using the pre-defined groups:
+ Project Server default Administrators Group
+ Project Server default Executives Group
+ Project Server default Portfolio Managers Group
+ Project Server default Project Managers Group
+ Project Server default Team Leads Group
+ Project Server default Team Members Group

These are viewed via PWA -> Server Settings -> Manage Groups. I've changed
no permissions, everything is as it was out-of-the-box.

The syncronizing is working fine. I've gone in and set some users to be
"resources" via their resource profile.

When I access a project workspace and check advanced permissions (site
actions -> site settings -> advanced permissions), I see that users who are
part of the Project Server default Executives Group now have Readers
(Microsoft Office Project Server) rights, which as I understand it would give
them read-only rights access to the workspace. This is ideal but untested at
this point (I'm not comfortable letting the execs go on it utill I see it all
working perfectly). I see no other users (except myself - admin).

I open up the workspace project plan in Project Pro 2007 and using the Build
Team from Enterprise feature, I pick several users that are part of the
Project Server default Team Members Group. I don't assign them to a task just
yet, I just make them part of the team. Save, publish and check-in the
project plan.

I return to the workspace and check the advanced permissions (site actions
-> site settings -> advanced permissions), I see that the resource users I
added to the project team have been added and have the same rights as the
executives: Readers (Microsoft Office Project Server). Considering that the
team members weren't actually assigned any tasks yet, I'm thinking Read
rights is all they need. So far so good.

Here's where my confusion begins. The project-assigned team members can see
the project workspace link/name on the PWA start page, but when they try to
access the workspace they get the "Error: Access Denied" message.

Did I miss a step along the way? I'm not sure why Read (Microsoft Office
Project Server) rights are not allowing the team member to actually access
the workspace.

The ideal setup for me would be to:

1) Utilise the default user groups of PS2007 that are synced with AD and not
create groups anywhere else
2) Utilise the established default PS2007 rights of those groups
3) When a resource is assigned to a project plan, allow them to access the
workspace
4) When a resource is assigned to a task in project plan, allow them to
access submit timesheets etc. and access to the workspace

Do I have to do something different to accomplish the "ideal" setup above?

Prior to the AD synching, I was using what I assumed were WSS user groups
and assigning usique permissions at each workspace but this is not a good
solution for me because I want to limit who can see a workspace by project
teams.

Some assistance with this would be greatly appreciated. I see several other
permission-type threads but I was unable to find any that posed the question
in this manner (simple).

Thanks in advance.

 

[Steven Douglass]

I think I'm narrowing this one down a little more.

Not all workspaces reproduce this error even though the user has the same
rights: Read (Microsoft Office Project Server).

I have a hunch that sites that previously had "Inherit permissions from
parent" enabled, are now causing access error due to the fact that the site
no longer uses inheritance for it's permissions (I changed it when we got AD
group sync set up)

I believe this because I can create a new site that does not use parent
permissions and everything is fine and the user with Reader (Microsoft Office
Project Server) rights can access it as expected.

Without knowing what to look for in the DB as far as dangling permissions,
my workaround is to re-create the project plans and workspaces to ensure that
from birth that the workspaces don't inherit parent site permissions.

Luckily for me, most of the projects are new and have little progress
recorded. I am going to keep one of the sites that has issues so I can dig
into the DB and see if there is some bad data in there as a result of
swithing the permission structure.

Oh, as a follow-up to the Team Member that got Readers (Microsoft Office
Project Server) instead of Team members (Microsoft Office Project Server)
permissions to the site, this one is related to the sequence in which you add
the user to the project/task. If you add the resource to the project plan
without assigning a task then publish, they get Read rights. If you then add
them to a task and publish, they retain the Reader right permission (it does
not change to Team member as one would expect). If you add the resource to
the project plan and immediately assign them to a task (before publishing the
plan), the resource then get Team member rights. The other option is to
remove them from the project, publish, then add them again but this time
assigning them to a task before publishing.

Shooting 0/3 on issue resolutions but 3/3 on workarounds.