Table of Contents	Introduction
	CEE Users and Roles
	Organizing Multiple Projects
	User Groups and Project Groups
	Public Projects
	Project Categories
	Conclusion
	Appendix A: Standard CEE Roles

Organizing Multiple Projects

Previously in this document we discussed organizing users within a single CEE project, using CEE roles and resource patterns to give different users different levels of access to project data. However when an organization has more and more users and more and larger collections of source code and documents, the need for an understandable organization of project-related material and for differential access to that material increases to the point where it is easier to create multiple CEE projects than to try to organize all activities within a single project.

You may encounter two typical situations when you consider how to organize multiple projects in CEE:

• When attempting to separate material and users into separate projects, you may find that the projects are (for the most part) unrelated to and independent of each other.  In this case it is also likely that the people who need access to a particular project are (for the most part) different than the people who need access to any other project. (In other words, each project may have a set of users mostly unique to it and not shared with any other project.)
• On the other hand, you may find that the projects are (for the most part) related to each other, and can be thought of parts within a larger whole, i.e., as individual efforts within an overall initiative encompassing all of them.  In this case you may also find that there is a core group of people who need some basic level of access to all projects, with some of those people needing a higher level of access to only a few of those projects.

Where projects are not (for the most part) related to each other and do not necessarily have the same users, we can treat the projects independently, creating each one as a top-level project. Where projects are parts of a larger whole and may share a core group of users, we can organize the projects as subprojects of one overall project. We discuss both these approaches in the following sections.

Multiple Independent Projects

In this section we consider the case where projects are not related to each other and each project’s users are (mostly) unique to it and are not shared with any other project (at least, not shared to any great degree).

For example, suppose that we have three disjoint groups of developers and other users within an organization: The three groups are working on development projects that are completely independent of each other, so that the groups do not share code or other data or otherwise interact with each other. However the groups wish to share the services of a single CEE system provided as a central service for use by anyone in the organization.

The most straightforward approach to meeting the groups’ needs is simply to create three separate CEE projects, and assign people to each project as appropriate:

• Create the first project as a top-level project and as a private project.
• Repeat the process to create the second and third projects.
• Create a CEE user-id for each person in the three groups to be using the projects.
• For each person in the first group, add their user-id to the first project and grant an appropriate role to the user-id: Developer, Observer, or whatever other role is appropriate given the part that person will play in the project.
• For each person in the second group, add their user-id to the second project and grant an appropriate role to the user-id as previously discussed.
• Repeat the process for everyone in the third group, adding each person’s user-id to the third project and granting to them appropriate roles.

Even though everyone in this example has a user-id on the same CEE system, any given person has access only to the project to which that person’s user-id has been added, and within that project the person has permissions only for those actions allowed by the person’s assigned role. For example, a given person might have a user-id that was granted the Developer role in the first project, allowing the person to add and modify data in the project’s version control repository; however the person would not have access to any data associated with the second or third projects. (In fact, since in our example the projects are private and not public projects, the person in question would not even see the other projects listed under the “Projects” page.)

We could continue to add additional projects and users as desired, so that a given CEE system might contain dozens or even hundreds of independent projects, each with its own group of users.

User Access to Multiple Projects

In the above example all the projects were assumed to be independent and to have their own exclusive user communities, so that a person working on one project would not have access to any other project on the same CEE system. However in some cases we may wish to have a given person participate in multiple projects.

This is quite simple to do: Simply add the person’s user-id to each of the other projects, exactly as was previously described, and grant to the user-id an appropriate role within each project. Note that a given user-id may be granted different roles in different projects. For example, a given person may have the CEE Developer role in one project, but have only the Observer role in another project.

A Project with Subprojects

In the previous section we discussed configuring access where projects are not related and each project’s users are mostly unique to it and not shared much with any other project. In this section we discuss the situation when we have multiple projects that form part of a larger initiative and most of the users may be in a core group that needs access to all projects.

Where projects are related to each other and/or share a large core group of users, you can create a top-level CEE project and then create other projects as subprojects of the top-level project, with one set of activities per subproject. You can then grant roles in the top-level project to the core group of users, and depending on the role configuration, they will then also have those roles in each of the subprojects. (As with a single project, you can grant different roles to different users.)  Users assigned to roles which do NOT have ‘Block recursion into private projects’ checked will be able to access sub-projects under the top level project.  They will inherit the permissions associated with the role(s) they are playing in the top level project.  Users playing roles with the ‘Block recursion into private projects’ checked will not automatically gain access to the sub-projects. 

Previously in this document we discussed a situation where twenty people needed access to a project, with five people in the Developer Role and the other people in the Observer role. Continuing with that example, suppose that this group’s company has an initiative in which it works with ten other companies acting as partners on individual projects within the initiative, one project per company. In this case the core group of 20 people will need access to the initiative as a whole and to these ten projects within the initiative, with each individual project also being accessed by one or more representatives of the company acting as a partner for that project.

You can create a suitable configuration for this in CEE as follows:

• Create an initial project as a top-level private project as described previously. This project will serve as a parent project for the other projects, and can be used to manage material and activities related to the initiative as a whole.
• Create a CEE user-id for each of the twenty people, as described previously.
• Add each user-id to the top-level project as described previously, granting to each user either the Developer role or the Observer role as appropriate.
• Create a project for the joint work with the first partner company, as a private subproject of the top-level project. (In other words, select the “initiative” project for the “Parent Project” field, and leave unchecked the “Public Project” checkbox.)
• Create CEE user-ids for the representatives of the first partner company, as described previously.
• Add each of the partner company’s user-ids to the subproject, granting to them an appropriate role (e.g., Observer or Developer) in the subproject. (Be careful to ensure that you have the subproject properly selected first before adding user-ids.)
• Repeat the previous three steps for each of the remaining partner companies.

In this configuration each partner company’s representatives can access only the particular (sub)project in which they have been granted roles; they cannot access other subprojects, nor can they access the top-level project. (In fact, since both the top-level project and its subprojects are private, the partner company’s representatives will not even see the top-level project or the other subprojects listed on their “My start page” or “Projects” pages.)

The members of the 20-person group can access the top-level parent project for the initiative as a whole, and any of the materials and activities associated with that project. Based on the roles they are playing, they can also access each of the ten subprojects, and will have the same role within those subprojects as they were granted in the top-level project – in other words, roles in the subprojects are inherited from roles in the parent project.¹ (In CEE such an inherited role is a special case of what are referred to as derived roles, as opposed to direct roles that are explicitly granted to user-ids within a project. We will consider other kinds of derived roles later in this document.)

Using Inherited Roles

Note that when a user’s role in a project is inherited from a parent project the CEE interface appears differently than when the user’s role is directly granted within the project itself. (This is true for derived roles in general, as discussed in subsequent sections.) In the example, although members of the core group have (inherited) roles in the ten subprojects, the subprojects do not appear on the users’ “My start page”, and thus cannot be accessed from that page. To access one of the subprojects, a core group member could go to the top-level parent project (from either their “My start page” or the “Projects” page) and then access the desired subproject using the appropriate link under the “Subproject” section of the parent project’s home page.

Also note in our example that when a core group member accesses the home page for a subproject, the subproject’s home page will display a “Join this Project” link, even though the member already has a role in the subproject inherited from the parent project. This behavior occurs because a user is considered to have “joined” a project only if the user has been directly granted a role in the project and is on that project’s membership list. However in this case there is no need to join the project explicitly, unless the user would like to request a different role in the project; the user can simply ignore the “Join this Project” link and proceed to access project functions as the user would normally do.

Finally, note that the subproject’s home page does not show a user’s role in the project unless the user has actually joined the project. In order to see what inherited role they might have in a project, users can look at their own profile (using the “Edit profile” link in the top navigation bar) on the “Edit user” page, follow the “Direct and derived roles” link (in the “Detailed role info” section of the page) to go to the “User roles” page, and then invoke the “Show derived roles” operation. The resulting page displays the user’s derived roles for all projects on the CEE system (in the “Derived roles” section of the page).

Further Customizing Access in Subprojects

Continuing with our example, suppose that a given member of the core group has the Observer role in a particular subproject, having inherited that role from the parent top-level project; however suppose that instead the user in question actually needs to have greater access to the project, e.g., the access associated with the Developer role.

This can be easily done: We can simply add the person’s user-id directly to the subproject in question, and grant to the person the Developer role in that subproject. The person will then have two roles in the project: the Developer role (directly granted) and the Observer role (inherited from the parent project). The user’s permissions in the project are the union of the permissions from the two roles; in other words, the person can do anything allowed by the Observer role, as well as anything allowed by the Developer role. (Since the permissions associated with the Developer role are a superset of the permissions for the Observer role, in effect it is as if the user had only the Developer role.)

Note that in this case the user is considered to have joined the subproject (since they were directly granted a role in the subproject) and thus the user will now see the subproject listed on their “My start page”. (However they will still not see subprojects listed in which they have only an inherited role.)

Note that this is not necessarily true in all cases: as discussed later in this document, a particular role can be configured so that it is not inherited in a private subproject (which happens to be the type of the projects in this example). However the standard CEE Developer and Observer roles used in the example are inherited in all subprojects, private or public.

---

---