Creating Categories
| You use Categories to define data permissions. For example, data permissions include the See Projects in Project Center View permission. What projects will be visible in that view are described by the data restrictor also found in the Category. So, Categories allow data to be seen and managed and may restrict the data to be seen and managed by a user. Like the Groups page, Categories also have sections, explained individually in the following sections. Also, there are Microsoft default Categories, which are not roles based. The defaults and an optional Category design are discussed in the "Optional Category Configuration" section later in this chapter. After all the Templates and Groups are defined and proper selections made, it is time to define the Categories. Perform the following steps:
The default Category names are not like the Groups or Templates in that they describe what data permissions are necessary for a function in the organization. The default Category names are as follows:
When open, the Category page has sections distinguished by blue letters and a blue line across the page, as shown in Figure 8.9. Figure 8.9. The Category page has defined sections. Category Name and DescriptionTo add or rename a Category, you must type in the name and description. It is suggested that you create a description that reminds you of the overall reason for this Category. Users and GroupsIn the Available Users and Groups list, select the Group(s) you want this Category to be assigned to and select the Add button to associate the Category and Group. TIP It is strongly recommended that only Groups be assigned to Categories and never individual users. To maintain the integrity of the security model, users should be assigned only to Groups. If you assign a user to a Category, assign a Category to a Group, and assign users to Groups, you will experience unexpected security behavior at the user level. Troubleshooting this condition is extremely difficult. NOTE A Group must be assigned in the Users and Groups with Permissions window for the permissions selection window to become active. For each Group in the Users and Groups with Permissions window, set the permissions in one of two ways:
TIP Do not select Deny in the Category. Because Deny is absolute, it is better to have the Allow/Deny selection blank, creating a soft Deny. Deny is best used only at the Select Features level turning a permission off for everyone. The 14 data permissions in the Permissions window are actually controlled by the Category. Setting the Category permissions in the Category is the right thing to do. The data permissions are as follows:
It is possible to set these 14 permissions in the Group. If these data permissions were defined by the Group, after the Group is assigned to the Category, the Category permissions defined in the Category will overwrite the Group-defined permissions. For each Group added to the Category, a unique set of data permissions will apply to specific Group/Category combinations. It cannot be overemphasized that these 14 data permissions are owned and managed by the Category regardless of your ability to change these settings elsewhere, such as in templates and in the Groups themselves. Projects: Select the Projects That Users in This Category Can ViewAfter the data permissions are set, the next sections of the Category page allow you to restrict the data according to radio buttons and security rules. The Projects section is the first of those areas of restriction (see Figure 8.10). Figure 8.10. Restricting data for projects. Under Projects: Select the Projects That Users in This Category Can View are two radio buttonsAll Current and Future Projects in Project Server Database and Only the Projects Indicated Below. All Current and Future Projects in Project Server Database Radio ButtonThe All Current and Future Projects selection means just that. If you allow the permission See Projects in Project Center, all current and future projects will populate the Project Center view for any Group with this Category assigned. This equates to no data restriction. Only the Projects Indicated Below Radio ButtonIf you want to restrict the data in this Category, choose the Only the Projects Indicated Below radio button. This selection has two additional choices to determine the restriction. The Available Projects window displays the current projects in the database. By selecting one or many of these projects and clicking the Add button you restrict this Category's projects to only those projects in the Projects in This Category window. Seldom, if ever, will you restrict a Category to a select set of projects. On one occasion it was necessary to use this restrictor. A client had a very sensitive project that he wanted only two people in the company to see. An "eyes only" Category was created with only this sensitive project added. This Category was associated with a special Group with only two members and thus accomplished only two people in the company being able to view the sensitive project. Leaving the Projects in This Category window blank is usually proper because a series of security rules follow, which assist you in restricting the data according to the rules you choose. These rules are
The first two rules are based on who created the project and whether the user is a member of a project team. The second two rules are based on the RBS.
Under the security rules, the system decides how to populate the Project Center view, for example. If you select rule one, your view is populated with only those projects on which you are the creator, also known as the owner in Project Server. If rule two is selected, you see only those projects on which you are a team member. If you select both, the effect is additive. You see your projects as a creator and a team member. The third rule assumes that you have people reporting to you. How the system knows about who reports to whom is through the RBS. If you have people reporting to you who are project creators, your view includes all the projects that are true for the first two rules and all the projects of your resources who are project creators. The fourth rule adds to your view all the projects on which any of your reporting resources is a team member. Using the rules allows the system to dynamically populate your views according to the restrictions you choose. Available Project ViewsThe last project restrictor enables you to decide which project view users in this Category can see in the View a Project view, which gives the details of the individual projects visible in PWA.
Your ability to restrict project data is highly customizable using Categories. Let's continue defining Categories by looking at the next section of the Category page. Resources: Select the Resources Whose Information Can/Cannot Be Viewed by Users in This CategoryNow that the project restrictions have been set, the next section of the Category page allows you to restrict resource data visible in the Project Web Access Assignment and Resource Center views (see Figure 8.11). Figure 8.11. Restricting data for resources. The section Resources: Select the Resources Whose Information Can/Cannot Be Viewed By Users in This Category contains two radio buttonsAll Current and Future Resources in Project Server Database and Only the Resources Specified Below. All Current and Future Resources in Project Server DatabaseThe All Current and Future Resources selection means just that. If you allowed the permission See Enterprise Resource Data, all current and future resources in the Server Database will populate the Resource Center view for any Group with this Category assigned. This equates to no data restriction. Only the Resources Specified BelowIf you want to restrict the resource data in this Category, Only the Resources Specified Below is the appropriate choice. This selection has two additional choices to determine the restriction. The Available Resources window displays the current resources saved in the database. By selecting one or many of these resources and clicking the Add button, you restrict this Category's resources to only those displayed in the Resources Whose Assignments Can/Cannot Be Viewed window. Seldom, if ever, will you restrict a Category to a select set of resources. Leaving the Resources Whose Assignments Can/Cannot Be Viewed window blank is usually proper because a series of security rules follows, which will assist you in restricting the data according to the rules you choose. These rules are
The first two rules are based on who created the resource and whether the user is a member of a project team. The second two rules are based on the RBS. Under the security rules, the system decides how to populate the Resource Center and Assignment views, for example. Selecting rule one populates your view with only your own resource information. Selecting rule two shows you only those resources assigned to projects for which you are the creator. If you select both rules, the effect is additive. The third rule assumes that you have people reporting to you. How the system knows about who reports to whom is through the RBS. If you have people reporting to you, your view includes all those resources. The fourth rule restricts your resource data to only your direct reports. For example, if you were a division manager, only those managers who report to you would be displayed, not every resource in your division. Using the rules allows the system to dynamically populate your views according to the restrictions you choose using the security rules. Available Assignment ViewsContinuing with resource restrictors, you need to decide which assignment views users in this Category can see in the View Assignments view, which shows the details of the individual resource assignments visible in PWA. Available Resource Center ViewsNext, you need to decide which Resource Center views users in this Category can see in the Resource Center in PWA. Project Center ViewsUnder Project Center Views: Select Views for Displaying a Portfolio of Projects, the last set of Category data restrictors is the selection of Project Center views, Portfolio Analyzer views, and models you want a user to see (see Figure 8.12). Figure 8.12. Restricting data using views. The list of views in the Available Project Center Views window shows all the views currently created for the Project Center. By selecting the views that a Category manages, you restrict the data available to the users. For example, the best views for an Executive are usually less detailed than for a Project Manager. Select the appropriate views for this Category and click the Add or Add All button to apply the appropriate views.
The list in the Available Portfolio Analyzer Views window shows all the views currently created for the Portfolio Analyzer. Select the appropriate views for this Category and click the Add or Add All button to apply the appropriate views. NOTE During the initial installation, no Portfolio Analyzer views will be available. No default Portfolio Analyzer views exist in Project Server. Portfolio Analyzer views must be created for each specific client. As Portfolio Analyzer views are created, they can be assigned to Categories during the view creation process.
The last selection in the Category is Models. Select the All Current and Future Models in the Project Server Database radio button to allow users who have permissions to this Category to see all models. Select Only the Models Specified Below if you want to restrict the available models. Just like in Projects and Resources, you can restrict this Category to only a specific set of models visible in the Available Models window, or you can select security rules to manage what models are visible, such as the following:
The first rule is based on who created the model, and the second rule is based on RBS. NOTE If you do not want to display any models for a Category, choose Only the Models Specified Below and do not select any available models or either security rule. Under these conditions, nothing is selected below, and, therefore, nothing will be displayed. Optional Category ConfigurationThe Project Server default Categories describe well how data permissions and restrictors manage the flow of data for Groups of users. However, the default Categories do not follow the roles-based convention displayed by templates and Groups. Because the security model is complex, it may be more advantageous to you to create Categories with the same names as Templates. By changing the Categories to roles-based names, you can remember the reason for a set of user permissions, data permissions, and restrictors because all the permissions are kept in the template. Because the template is the master permissions library for a role, the Set with Template button transfers template permission knowledge to the Group and to the aptly named Category. Under these conditions, the template is the master security model for each role's permissions and can be the place where all security changes are maintained. After a template is altered, the corresponding Group can be Set Permissions with Template, and repeating for the corresponding Category means that the permissions are always managed in only one place, the template. As you have seen, there are at least five different places where a permission can be set. Remembering where you put all the check marks can be daunting. It is suggested that the check marks be maintained in the template and applied through the Set Permissions with Template button in both Groups and Categories. Both the default Categories and the optional naming of Categories work. Choose the one that helps you remember and maintain the security model for future expansion and more complex permissions as your system evolves. |
EAN: 2147483647
Pages: 227