Add new resource / RBS

[ctd]

Hi,
I have a client requirement to add new resource using PWA only. With the
following requirement, I'm not sure if I should add new resources under the
RBS look up table or just add them using the Manage Users/Groups option.

Level 1 - Department
Level 2 - Group (with security permission)
Level 3 - Users/Resources.

The requirement is that resources under one department can only view
projects under that department, except for those in the Admin group can view
projects across departments. Also another requirement is that if I select a
department (level 1) and a group (level 2), I should be able to see all
resources (level 3) under it.

To test out, I created a RBS look up table with 3 levels. I also created
new users using Manage users/groups option and assign the correct level of
RBS to them.

Now when I tried to look into the published database, I was able to see the
RBS look up table values with all 3 levels, but for all users being added
only thru the manage users/groups option, I saw their name under the resource
table, their group in the "MSP_web_security_group" table, but can't find
their department anywhere. So, my question:

1. Between RBS look up table and Manage Users/Group option, what is the
correct way to add a new user with group level/permission and depart. level
info ?

2. When I create a RBS look up table, should the entity be "resource" or
"project" ?
so that if I create a new project thru PSI, I will be able to assign
resource and any custom field to that project.

3. How do I retrieve a list of resources if I know their department/group
value ?
If I add resources thru RBS look up table, then it's just a simple query.
But if I add resources thru Manage User/Group option, I don't have the answer
yet.

4. If I follow the RBS structure above (dept - group - user), then how can I
overwrite the permission for any new admin - who doesn't belong to any dept.
and should be able to view all projects.

Sorry for a long post, and thanks in advance.
ctd

 

[Andrew Lavinsky]

1) Add the user to the resource pool. Assign the appropriate metadata such
as RBS at this time. Once they've been added to the resource pool, assign
them to the appropriate user group. Configure all security on the group
level, or in the categories that are assigned to the group.

2) RBS is applied to Resources and not Projects. The RBS security model is
governed by which Resources have save permission, are status managers within
the project, or are project owners, etc.

3) You would develop a list by RBS by reviewing them in the Resource Center,
or opening the resources in MS Project Professional. The RBS doesn't map to
specific User Groups typically. Think of the User Group as a particular
horizontal strata within the organization with the RBS defining the vertical
divisions that separate the same strata across departments/regions.

4) Admins are generally not assigned RBS codes - as they're admins. They
need rights to manage the entire system and see all projects. The RBS
basically applies to categories, and controls what folks can/cannot see.

Here's a link to a blog post on configuring/documenting MOPS security that
may be helpful:
http://blogs.catapultsystems.com/ep...ctices-in-documenting-mops-2007-security.aspx

 

[ctd]

Hi Andrew,
Thank you for your clear reply. I can set up my RBS and have things work
as expected now. Another question came up regarding RBS with custom webpart
dropping in PWA, can we control what custom page people can see or not thru
RBS ? or this will have to do in the code ?

Thanks,
ctd

 

[Andrew Lavinsky]

That cannot be done through the RBS. The RBS only controls which resources
are available in the Resource Center, and which projects are available in
the Project Center.

There're a couple of ways to control which webparts folks get to see when
they log in. Custom code is one option. Setting different pages based on
security is another (no code) option. You could also use webparts targeted
to specific audiences if you're using MOSS (search for "MOSS Webparts audience"
for more information).


- Andrew Lavinsky
Blog: http://blogs.catapultsystems.com/epm

 

[ctd]

That's what I suspected. Just wanted to confirm. Thanks.