The answer for Question 1 is above, in my first post.
Question 2:
If "X", "Y", and "Z" do not use Microsoft project, and you are referring to giving them read only access to the projects in PWA ("Project Center"), then you can achveive this by adding "X", "Y", and "Z" to the Team Members group (under PWA -> Server Settings -> Manage Groups. ) Then Project Managers "B", "C", "D" and "E" should add these resources to the project teams for the project that they want to grant visilbilty to. (Press Ctrl-T in MS Project Professional to reach the Build Team interface.)
I think the same procedure will answer question 3.
To address some of your other requirements:
""B", "C", "D", "E" should be able to create projects"
Add "B","C", "D" and "E" to the Project Managers group in PWA -> Server Settings -> Manage Groups.
""A" user should be able to create and edit projects created by "A","B", "C", "D", "E" users"
There are a few ways to accomplish this. If you are fine giving "A" the permission to open and edit any projects in the server instance, make them a member of the "Portfolio Managers" group. (Note this group does _not_ have permissions to publish projects, though.)
If "A"'s permissions need to be restricted to just the projects saved by "B", "C", "D", and "E" but not others in the organization, you should try setting up the RBS:
To set up the RBS, first create a hierachical Lookup Table in the RBS lookup table. PWA -> Server Settings -> Enterprise Custom Field Definition. Select "RBS" in the "Lookup Tables for Custom Fields" section (not in the top "Enterprise Custom Fields" section.) Setting up the appropriate RBS could be an article itself, but you might want something like:
Company (Contoso)
Group 1 (HR)
Team 1 (Benefits)
Team 2 (Payroll)
Group 2 (IT)
Team 3 (Windows)
For the case you provide, you only need two entries, but one must be indented below the other.
Save the changes to the RBS. Go back to the Manage Users screen, and click on "A". Set their RBS value to be a parent, such as Group 1. (This will often match the corporate hierarchy group name that "A" is a member of.) Save, and edit "B","C","D" and "E", giving them RBS values which are below "A"s RBS value in the hierarchy (indented below A or one of its children, not indented below another group.) In the example I provided, they would be set to Team 1, with "A" assigned to Group 1.
Now, the big change for this: This involves changing the out-of-the-box security: you may want to do this with a new category instead of altering the standard category! If you create a new category, you will need to connect it to the Project Managers group. But far simpler is to just change the "My Projects" category. Go to PWA -> Server Settings -> Manage Categories and click on "My Projects" to open it up. In the section titled "Projects" you will see three check boxes selected. Change the selection on "The Project Owner is a descendant of the User via RBS" so that it is selected as well. Save the changes to the Category.
Users "A" needs to be in the Project Managers security group.
Now any member of the Project Managers security group will have full permissions on any project owned by someone beneath them in the RBS.
This covered a lot of ground, and I know that I didn't provided detailed steps for some portions. Let me know where you need more information and I will try to provide it.
James Fraser
