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

CEE Users and Roles

A Simple Example

We start with the simplest possible CEE configuration: a single project with only a single person using the project. We assume that no one else has access (or should have access) to the project. In CEE you can create this configuration as follows:

• Create the project and specify that it be created as a top-level project and as a private project. (In other words, select the “New top-level” item for the “Parent project” field, and leave unchecked the “Public project” checkbox.)

• Create a single CEE user-id and assign the user-id to the person to be using the project.
• Add that user-id to the project and grant the user-id the Project Owner role (or another appropriate role) within the project.

The person using the project could then login to CEE under their assigned user-id, after which they would have all access to all resources available as part of the project: the version control repository, the file sharing area, the issue tracking system, and so on.

(If you grant the person the Project Owner role then they will also be able to reconfigure the project itself in various ways. If you wish to prevent the person from doing this, assign the person the Developer role instead.)

Also note that the creator of the project is automatically assigned the project roles that are configured to ‘Grant role on subproject creation’ in the Administration àRoles area.

Multiple Users in a Project

Continuing with our example of the single-person project, let’s suppose that a second person wants to use the project resources, and that we wish to permit this person exactly the same level of access as the first person who was granted access.

To do this, assign the second person a second CEE user-id, and then let the first and second persons each login to CEE using their own respective user-ids. Using separate user-ids has the following advantages (among others):

• Using separate user-ids allows better tracking of people’s actions within the project. For example, if the two people use different user-ids and make changes to the version control repository then it is possible to determine who checked in a particular change.
• Using separate user-ids allows people to file issues against each other. For example, if the two people in our example divide up the project tasks between each other, one person can use the project or issue tracking system to assign the other person a task relating to that person’s area of responsibility.

Create the new user-id and add the new user to the project as described above, and grant the user-id the same CEE role as the first person, e.g., Project Owner in our example.)

Roles

To continue with our example, suppose that we want a third person to have access to the project, and a fourth person, and so on. If each person is to have the same access to the project as the first person, then doing this is simple: We create a new CEE user-id for each new person and add that user-id to the project, exactly as described above for the second person.

This presumes, however, that all the people working in the project are to have the exact same access. What if we want some people to have different access than other people? For example, we might want some people to be able to modify the version control repository (e.g., to “check in” changes), and other people to be able only to read from the repository (e.g., to “check out” code).

To do this we can use CEE roles, and assign different roles to different users. A role is essentially a set of permissions specifying what a user can do within a project; the permissions are expressed in terms of actions that the user can perform with respect to each of the resources within a project.¹ For example, a person needing the ability to change the contents of the version repository would need permission to add new files to the repository (the “VersionControl – Add” action in CEE terms), permission to make changes to existing files in the repository (“VersionControl – Modify”), and so on.

Rather than requiring each of these permissions to be granted separately, CEE bundles all the necessary permissions into a role, which can then be granted to a particular user. For example, the standard CEE Developer role includes all the permissions necessary for a person who makes changes to a project’s version control repository. The Developer role also includes other permissions useful for people who do code development, for example, permission to upload files to the file sharing area or to make changes to issues previously submitted to the issue or project tracking system. By granting to a particular user the Developer role within a project, we ensure that they have all the necessary permissions they will need, and do not need to specify those permissions individually.

Continuing with our example, suppose that we wish to have twenty people participate in the project, with five of the people having relatively full access to all project resources, and the other fifteen people having primarily “read only” access to those resources. We can assign the five people a CEE role giving relatively full access (e.g., the Developer role, or perhaps even the Project Owner role), while assigning the other fifteen people a CEE role giving relatively limited access (e.g., the Observer role).

In CEE terms you can do this as follows:

• Create the project as a top-level private project as described previously.
• Create a CEE user-id for each of the twenty people, as described previously.
• Add each user-id to the project. If the user-id corresponds to one of the five people with relatively full access, then grant to the user-id the Developer role (or an equivalent role) within the project. On the other hand, if the user-id is for one of the fifteen people with limited access, then grant to the user-id the Observer role (or an equivalent role) within the project.

As noted above, the default CEE configuration provides a set of standard roles that can be granted to users, including the roles Project Owner, Developer, Content Developer, and Observer. (See Appendix A for more information on all the roles included in the default CEE configuration.) If you need to grant to a group of users a set of permissions that do not exactly correspond to those of the standard CEE roles, you can either modify the permissions for one or more of the standard roles or create one or more new roles. For more information on modifying or adding roles, see the CEE online help documentation.

Internally Partitioning Projects

Our example configuration now consists of a single project with multiple users, with each user assigned to one of several possible roles (in the CEE sense) within that project. In the next section we will expand our discussion to include multiple projects. However before doing that we discuss the advantages and disadvantages of centralizing all activities and users in a single project.

One major advantage of using a single project is that this minimizes the number of places users have to go to in order to get their work done. For example, if all code is stored in a single project then users can use a single version control checkout operation to get a copy of all the code.

Even if you are working with multiple different components and multiple areas of activity, you can still consolidate those components and areas within a single project, by doing the following:

• Create separate directories (or subdirectories) within the version control repository, and store separate collections of source code in different directories.

• Create different components (or subcomponents) within the project or issue tracking system, so that new artifacts can be associated with a particular component.

• Create multiple discussions, one for each component and/or area of activity.

• Create multiple folders (or subfolders) within the file sharing area, so that documents for different components or areas of activity can be stored in different folders.

Such a scheme allows you to impose a considerable degree of internal organization on a project, while still allowing users easy access to project resources. Note that with one exception (described below) this internal partitioning scheme does not support specifying different access controls for different project resources of the same type. Thus, for example, although you may organize the project file sharing area to create different folders and subfolders, corresponding to different components within the project, a given user would have the same access to all documents no matter in which folder or subfolder they were located.

However it is possible to place different access controls on different components of the code in the project’s version control repository. For example, you may have multiple development teams and may want to allow any particular team to change the code only for the components for which they are responsible. You can do this in CEE within a single project using CEE resources, as described below.

Resource Patterns

CEE resources can be used to specify particular directories and/or types of files within a project’s version control repository, and then to customize permissions to refer to those directories and/or files. For example, suppose that within a single project we would like to maintain four separate collections of source code. We assume that the various collections of code are part of a single application, so project developers will be checking out and using all four collections together; however we also assume that the developers have been divided into four teams, one for each collection of code, and we want to ensure that a team can make changes to its own collection, but not to collections associated with the other teams.

You can create such a configuration with CEE as follows:

• Create four top-level directories within the project’s version control directory; for this example we’ll refer to these directories as “alpha”, “bravo”, “charlie”, and “delta”.
• Create four new CEE resource patterns associated with the project, one for each directory: “alpha/.*”, “bravo/.*”, “charlie/.*”, and “delta/.*”.²
• Create four new CEE roles using the Developer role as a model; in this example we will name the roles “AlphaDeveloper”, “BravoDeveloper”, “CharlieDeveloper”, and “DeltaDeveloper”. For each role, set the appropriate version control related permissions to allow commits and other related actions³ only for the corresponding resource patterns. Thus, for example, the AlphaDeveloper role would be allowed to do read-only operations on any part of the repository (represented by the “.*” resource), but allowed to do commits and related actions only for the directory represented by the “alpha/.*” resource. Note that resource patterns are additive. Giving a role multiple resource patterns will allows users playing that role to have the corresponding accesses to multiple areas within version control.
• When adding developers in the “Alpha” team to the project, grant to them the AlphaDeveloper role, and similarly when adding developers in the other teams grant to them the role associated with that team. If a developer needs to be able to change code in two collections, grant to them the roles corresponding to both collections and teams. If a developer needs to be able to change code anywhere in the repository, grant to them the standard Developer role.
• The four permissions that are used the most often in conjunction with resource patterns to limit access to the version control directory structure are:
  • VersionControl – Add
  • VersionControl – Delete
  • VersionControl - Modify
  • VersionControl - Read

Note that a similar scheme is used to distinguish the standard CEE roles Content Developer and Developer: As with the Developer role, being granted the Content Developer role allows a user to check out a copy of the entire repository; however the Content Developer role allows a user to commit changes to the repository only for files in the “www” directory used by CEE to store the project’s web pages.

You can also provide finer-grained control over who can read and/or modify web pages associated with the project, by defining different roles to have different access to resources corresponding to subdirectories of the “www” directory in the project’s repository.

Roles can also define permissions corresponding to actions taken at the CEE domain level, such as adding new users. However in this document we primarily consider permissions for actions taken within projects, since our goal is to describe ways to organize projects and users within projects.

In some CEE versions these resource strings should be proceeded with a slash character, e.g., “/alpha/.*”.

In CEE terms the permissions in question are for the “Add”, “Commit”, “Edit”, “Import”, “Release”, “Remove”, and “Tag” actions against the project repository, i.e., the actions “VersionControl – Add”, “VersionControl – Modify”, and so on.

---

---