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

Public Projects

Thus far we’ve discussed access control on private CEE projects, i.e., projects for which the “Public project” checkbox was not checked when creating the project. As we discussed above, private projects are not generally visible to users of the CEE system on which the projects are located. The exact rules are somewhat complicated, but in general the existence of a private project can be discovered though the standard CEE interface only by those users who are in the actual membership list for the project, or by those users who have a derived role in the project. (For users who are on the membership list for a top-level private project, the project would be listed on the users’ “My start page”, as well as on the “Projects” page. For users who have only a derived role in the project, the project would be listed only on the “Projects” page, and not on the “My start page”.)

In some cases we may wish to make the existence of the project known to every CEE user on the system, and allow users to view basic information about the project and then apply for membership in the project if desired. For example, we might want to create a project “utilities” to develop and distribute utility software that might be useful to any user on the CEE system.

We can create such a project as a top-level public project. (In other words, when creating the project select the “New top-level” item for the “Parent project” field, and check the “Public project” checkbox.)

The “utilities” project will then be visible to any CEE user through a listing on the “Projects” page. By following the project’s link any user may also view the project’s home page and view the project’s file sharing area, source code, issues, and other information. (We discuss below in more detail how access control works with public projects.) If they wish, users can make a request to join the project and be granted a specific role (e.g., Observer or Developer); their request is sent to the project owner(s), who can then approve or deny the request.

The Registered User Role

We noted above that any user of the CEE system can access the home page of a public project,¹ and can also access various content areas within the project. In fact, any user accessing the project has most of the access that a user with the Observer role would have; the major exceptions are that a user must have (at least) Observer status to be able to subscribe to project discussions or submit issues to the project’s issue tracking system.

Such default access to public projects is made possible through a special Registered User role. Each new user-id created in the CEE system is immediately granted the Registered User role, prior to the user being added as a member of any projects, project groups, or user groups. A user will then have the Registered User role in any² public project, even if their user-id has no other direct or derived role in that project.

In essence it is as if there were a project group consisting of all public projects in a CEE system, with all user-ids granted the Registered User role in that project group. Any user therefore has the ability to view public projects (in that unnamed project group), by virtue of having inherited the Registered User role within that project.

Private Projects vs. Public Projects

What about private projects? The Registered User role is configured so that it will not be inherited in private projects. (In CEE terms, the Registered User role has the “Block recursion into private projects” checkbox checked.) Thus any given user will not automatically have access to any private project, whether top-level private projects and private subprojects of public projects. As previously discussed, in order to access a private project a user must be granted at least the Observer role (or an equivalent role) in the project, or must otherwise have a derived role of least Observer (or equivalent) in the project.

In fact, this is probably the most important difference between the Observer role and the Registered User role (which otherwise have similar permissions): the Observer role is inherited in private subprojects, and the Registered User role is not. Thus if a user has the Observer role in a given project (or project group) then that user will have (at least) that same role in any subproject (or member of the project group), whether public or private. However if a user has only the Registered User role in a given project (or project group) then that user will have that role only in subprojects (or members of the project group) that are public.

Incidentally, note that registered users will not automatically have access to a public subproject of a private project (or a public project in a private project group). That’s because the Registered User role is not inherited into the private project (or project group), as discussed above, and thus is not available to be inherited into any subprojects (or members of the project group), even if they were explicitly marked as public.

“Semi-Public” Projects

Thus under ordinary circumstances it does not make sense to create public subprojects of a private project (or add public projects to a private project group). One exception is if you have the following environment and requirement:

• Within a larger CEE system you have a group of projects that are in general restricted to a specific group of people (call them “authorized users”), but not every person in the group has access to all the projects.
• You wish to make certain sets of documents and/or source code generally available to everyone in that specific group of people, while protecting the information or code from everyone else.

You can address this requirement by creating what we’ll call “semi-public” projects – essentially imitating what the standard CEE system does with public projects and the Registered User role, but within a more private context. The specific steps to do this are as follows:

• Create a private project (or project group) to be associated with the “authorized users”, i.e., the specific group of people with which we are concerned.
• Create a special role (for this example we’ll call it the “Authorized User” role) to be associated with the previously created private project (or project group). (In other words, make sure that the “Role visibility” field for the Authorized User role is set to the project or project group just created.) Give the role the same set of permissions as the Registered User role, and set the role to not be inherited in private subprojects. (In other words, make sure that the “Block recursion into private subprojects” checkbox is checked.)
• Grant the Authorized User role to all users in the authorized group of people. (You can do this either by granting the role individually to each and every user in the authorized group, or by granting the role to a special user group and then adding all the people to that user group.)

You can then create subprojects of the original project (or new projects in the project group), marking the new (sub)projects as either private or public. If the new (sub)project is to be a closed project that is not open (or even made known) to everyone in the authorized group of people, then you should set the (sub)project to be private. On the other hand, if anyone in the authorized group is free to join the project then you should set the (sub)project to be public. This allows anyone having the Authorized User role to inherit that role in the public (sub)project, and to be able to view project documents and request project membership.

However other CEE users not in the Authorized User role cannot access or view the (sub)project at all, even though it is ostensibly “public”, since such users do not have a role (whether direct or derived) in the (sub)project’s private parent project (or a project group of which it is a member). We therefore use the term “semi-public” to describe the (sub)project.

Public CEE Sites

Above we discussed how to create public CEE projects that are visible to every user of a CEE system. However thus far we’ve assumed that the only way to access CEE is to login under a given user-id, so that in order to see even the public projects a person must be a registered CEE user.

In some cases we may want to make CEE project information publicly accessible to anyone, whether they are a registered CEE user or not. For example, we may be using CEE to support a public open source development project, and we may wish to allow any Internet user to access basic project information. Alternatively, we may be using CEE on a enterprise intranet to support a “development portal” open to all developers and others within the organization, and would like employees to be able to try out the system without having to obtain a user-id first.

In order to support such use, a CEE system can be configured to make user registration optional. When a person connects to such a CEE system, they can skip the login step and proceed directly to access information relating to public projects on the system.

Even though such a person does not login to CEE, they are still treated as if they have a valid CEE role, namely the Anonymous Guest role. Unlike any other CEE role previously described, it is not necessary to login to a CEE site in order to be associated with the Anonymous Guest role; instead the Anonymous Guest role is assigned by default to any person who is accessing a public CEE site and who has not explicitly logged in to the site.

The actions permitted to the Anonymous Guest role on public CEE sites are similar to those permitted to the Registered User role: Guest users may view documents and announcements in public projects, look at discussion archives, view and check out source code in the version control repository, and query the issue tracking system for issues. (When checking out source code, guest users should login using the user-id “guest” and a null password.)

However unlike registered users, guest users may not request roles in projects, submit issues to the issue tracking system, or do other things that require a person to have a valid CEE user-id. People wishing to have greater access to public CEE sites should register with the site to select a user-id and be assigned a password (or other authentication credential). They may then login to the site and have the access privileges associated with a registered user, as previously described.

Like the Registered User role, the Anonymous Guest role provides access only to top-level public projects and their public subprojects; the Anonymous Guest role is not inherited in private subprojects, so guest users cannot access private projects (if there happen to be any on a public CEE site) or “semi-public” subprojects of private projects (i.e., subprojects whose parent projects are private but which are themselves marked as public). However once a person registers as a user their user-id can then be granted access to private and semi-public projects, as previously described.

---

---