Project Categories
As more and more projects are created on a CEE site, it can become difficult for users to keep track of all the projects that are available. You can make it easier for users to find projects (whether public or private) by organizing them into project categories. A category is similar to a project group, but used for site organization rather than access control; a given category can contain multiple projects, and a given project can be a member of multiple categories. A category can contain either public projects or private projects or both, and can itself be either public or private, as described below.
Categorizing Public Projects
Suppose that our CEE site contains several dozen public projects, open to anyone who has access to the site. Because there are so many projects we’d like to organize them in some way, so that users can get a better idea of which projects might be of interest to them.
One way to organize projects is by the type of software applications they represent. Thus, for example, your organization may develop logistics applications for internal use, and have several public development projects related to such applications. (The projects in this example are public in the sense that any employee with access to CEE may view them; the projects would not necessarily be accessible by anyone outside the organization, unless there were good reasons to allow such access.)
Since the projects are public, any registered user of the CEE system can see the projects listed by going to the “Projects” page and selecting the “Projects” tab; however if there are many projects then the logistics software projects may be jumbled together with unrelated projects, and thus may be difficult to find.
To address this problem, we can create a new category, call it “logistics”, and add to the category all the projects related to logistics. Registered users can then go to the “Projects” page, select the “Categories” tab, and see “logistics” listed as a category. If they follow the “logistics” link they will go to a page wherein are listed all the projects belonging to the “logistics” category. From there they can decide which projects are of interest, and then access the projects by following their links. For more information on creating categories, see the CEE online help document.
Once you have created the category, it should be displayed on the “Projects” page under the “Categories” tab. If you later wish to add new projects to the category, you can do so in one of two ways:
- You can edit the category and add one or more projects to it.
- You can edit the project and change the “Project categories” field to select the category to which you wish to add the project.
You can also add a project to a category when you create the project originally, as described above.
Multiple Categories and Subcategories
In the example above we decided to organize projects based on the type of software they were developing, and created a “logistics” category to collect together projects related to logistics applications. You may also wish to organize projects based on other criteria; for example, you may wish to allow users to see all the projects sponsored by a particular part of the organization. You could then create categories such as “manufacturing”, “engineering”, “research”, etc., one for each organization, and then assign projects to each category as described above.
Note that it is possible for a given project to be included in two different types of category; for example, a logistics application sponsored by the manufacturing division could be included in both the “logistics” category and the “manufacturing” category. Similarly, a project jointly sponsored by two different divisions could be included in the categories associated with each division.
A project can be added to multiple categories either by editing each category individually to add the project, or simply by editing the project itself and changing the “Project category” field to have multiple values. (For example, if you are using Microsoft Internet Explorer for Windows, you can select multiple categories in the “Project category” field by holding down the “control” key while clicking on each of the categories you wish to select.)
If you do use multiple sets of categories, and you specify all the categories as “new top-level” categories (using the “Parent category” field as described above), then all the categories will be listed together on the categories part of the “Projects” page. If you intend to use multiple sets of categories to implement “multi-axis” browsing for projects, then you may wish to use subcategories to create multiple hierarchies of categories.
For example, suppose you wish to have three sets of criteria by which you organize projects: the problem area for which the application is intended, the sponsoring division, and the development and run-time infrastructure on which the application is dependent. You can create category hierarchies to support this project organization as follows:
- Create three new top-level categories, say “application-domain”, “application-sponsor”, and “application-environment”, as described above.
- Create the categories for application domain, e.g., “logistics”, “financial”, etc. When creating each category, specify the “Parent category” field to be “application-domain”.
- Create the (sub)categories for application sponsor, e.g., “manufacturing”, “engineering”, etc. When creating each category, specify the “Parent category” field to be “application-sponsor”.
- Create the (sub)categories for application environment, e.g., “apache-php”, “ibm-websphere”, “visual-basic”, etc. When creating each category, specify the “Parent category” field to be “application-environment”.
You may then add projects to one or more of the subcategories you have created. Note that when adding a project to a subcategory, you must edit the subcategory itself; it is not possible to add the project by editing the project itself, because subcategories do not show up as choices in the “Project categories” field on the “Edit project” page.
When users then go to the category listing (using the “Categories” tab on the “Projects” page), they will see the top-level categories listed. Subcategories can be seen by checking the “View subcategories” box. If they select a particular top-level category, say “application-type”, they will be shown the home page for that category, which will list the various subcategories within the category. Users can then select a particular subcategory to see the projects belonging to that category.
Note that in this scheme a particular project could be added to a top-level category instead of (or in addition to) a subcategory, if there were some reason you wanted to do that.
Thus far we have assumed that we will be categorizing only public projects, and that the category lists will be visible to any registered user of the CEE system. However you can also categorize private projects, and even have categories that themselves are private.
Continuing with our example above, suppose that the research division sponsors certain private projects that are open only to employees of that division, and that are not publicly known outside that division. If you wish, you can include such private projects in the “research” (sub)category containing the projects sponsored by the research division.
If an employee of the research division has at least the Observer role (or an equivalent role) in the private projects sponsored by that division, then that employee would see those private projects listed under the “research” category, along with all the public projects. However if the “research” catalog listing is viewed by an employee of another division, one who does not have any access to the research division private projects, then the list displayed to that employee would not include any of the private projects, only public projects.
Creating Private Categories
In addition to including private projects in a public category, you can also create a private category, so that even the category itself is hidden except to those specifically allowed access to it.
For example, suppose that in addition to the various corporate divisions mentioned above (“research”, “engineering”, etc.), the corporation in our example is working with a third party (“Acme Widgets”) to fund and manage various confidential joint development projects. For convenience we would like to include a category listing such Acme Widgets projects as one of the subcategories under the “sponsor” category, so that corporate employees working with Acme Widgets may have an easy way to find all these confidential projects. However at the same time we do not want other employees to know about the projects, or even to know that our example corporation is working with Acme Widgets.
We can do this by creating an “acme-widgets” category under the “sponsors” category, similar to the (sub)categories “research”, “engineering”, etc., that we created for projects sponsored by those divisions. However instead of making the “acme-widgets” (sub)category a public category, you should create it as a private category; in other words, you create the category as described above, except that you should leave the “Public category” checkbox unchecked.
In order to view a private category (or to see it listed as one of the available categories), a user must have at least the Observer role (or equivalent role) in the category itself. You can grant users roles in the category in the same manner as you would grant roles in a project or project group.
Note that by granting a user a role in the category you simply make it possible for the user to view the category itself (i.e., its existence). If the category includes private projects (which is the case in our example) then a user viewing the category would also have to have a role in those projects in order to see them listed in the category, as described above.
In our example we would also grant certain users roles within the various confidential projects relating to Acme Widgets, as well as granting them a role within the “acme-widgets” category itself. Such users would then be able to see the “acme-widgets” (sub)category listed under the “sponsors” category, as well as be able to see all the Acme Widgets projects listed under the “acme-widgets” category.
Note that roles can be inherited within categories and subcategories in a similar manner to regular projects and subprojects. Thus, for example, if a user is granted the Observer role in the “acme-widgets” private category described above, and you create new private subcategories within the “acme-widgets” category, the user in question with have the (derived) role of Observer within that category as well. However note that not all roles are inherited from a public category into a private subcategory; as with projects, the Registered User role is not inherited from a public parent category into private subcategories. In our example this allows a registered user to view the “sponsors” public category, but prevents them from viewing the “acme-widgets” private subcategory.
Also note that a role granted in a category is not inherited in projects that are included in that category. This situation is different from that of project groups, where a role granted in a project group is inherited in the projects that are members of that group. This difference reflects the different purpose of project groups versus categories: project groups are specifically designed as an administrative mechanism to support more flexible access control schemes, while categories are designed simply to organize projects for easier browsing by users (who presumably have been separately granted access to the projects).
China
Korea
Japan
Introduction 
Korea
Japan