Interesting case – migrating user permisions and project visibilit

[Dominik Chrzanowski]

For one of my clients, I’m performing a migration from their project
management system (custom development) to Project Server 2007. The most
demanding part of the migration is configuring user permision and project
visibility management. I’m looking for any ideas that could help me to
imitate the current project visibility and permision model in the most exact
way.

Right now there are few levels of project permision and visibility
management (to make things simpler lets asume that if user can see a project,
than he always can edit it):
- Global Roles – there are few roles that are defined at application level.
Users can be added to those roles. Each of those roles has a seperate view
with all projects.
- Roles on a department level. After choosing such a role, you need to
choose one department. Only then you can assign a user to the role in a
particular department. One user can be assigned to one role in many
departments.
o Visibility – each project has a property indicating a department
leading the project. Each user role has one view where logged user can see
all projects from all departments that are equal to departments assigned to
the user (in the particular role for which the view is dedicated)
- Roles on a unit level. Equal to the idea of roles on a department level.
Units are not equal to departments.
- Roles on a project level. There are few roles that are defined on the
project level. One user may by assigned to one or more of those roles in one
project. One user can be also assigned to different project level roles in
different projects.
o Visability – each project level role has its own view. The view shows
all projects in which a logged user is in a partcular role.

Remarks:
- In my opinion RBS cannot be used for defining what the user can see
because of one of the client requirements – a possiblility to define a user
assigment to many independent departments and units. Also a collection of
departments is completely independent from the units collection.

Questions for which I’m seaching answers:
1. How to assing a user to one or more roles on a project level?
The client will not accept a solution in which a user is assigned to 3 user
groups (for instance: Project Manager, Technical Analyst, Business Analyst)
and after assigning that user to Project Team, the user will receive
permision for all 3 roles. The need is to determine in which role(s) user is
in particular project
2. How to manage user permissions on a department and unit level, assuming
that:
a. There are 2 independent collections – units and departments
b. One user can be assigned to many units and / or many departments in one
time
c. The user’s project visibility should be a combination of user unit /
department assigments and project unit department assigments

Looking forward for all sugestions.

 

[Gary Chefetz]

Sounds like you'll need to write some code to accomplish this.

 

[Dominik Chrzanowski]

Ok, but is there any possibility to extent existing PS functionality (like
Project Center)? I would like to avoid creating completly new functionality
(similar to Project Center)

 

[Gary Chefetz]

Dominick:

You have Groups, Categories, the RBS, and users' relationships to specific
projects in your toolbox for creating your security model and you've already
accepted a condition from the client who says that you can't use some of
these tools to their fullest. On this side of the pond, we call that
"painting yourself into a corner." What you are proposing, exceeds the
capability of those tools, even if you were allowed to use them. There's
nothing in the system that maps to arbitrary roles by project, except for
groups. One way to do this would be to create an application that supports
the roles mapping and use it to dynamically assign users to groups or
projects to categories. Your other alternative is to work with the client to
massage the requirements to something that the system supports, which I
think is the logical choice.