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

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/epm/archive/2009/11/19/best-practices-in-documenting-mops-2007-security.aspx

"ctd" wrote:

> 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
> 

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" wrote:

> 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/epm/archive/2009/11/19/best-practices-in-documenting-mops-2007-security.aspx
> 
> "ctd" wrote:
> 
> > 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
> > 

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

"Andrew Lavinsky" wrote:

> 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
> 
> > 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" wrote:
> > 
> >> 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/epm/archive/2009/11/19/best-practice
> >> s-in-documenting-mops-2007-security.aspx
> >> 
> >> "ctd" wrote:
> >> 
> >>> 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
> 
> 
> .
>