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

Appendix A: Standard CEE Roles

This document has described briefly the various roles used in a standard CEE system. This appendix describes the standard CEE roles in more detail. The roles are divided into two general types, domain-wide roles and project roles, distinguished as follows:

• Domain-wide roles are not associated with any particular project or projects, but are granted for the entire CEE domain.
• Project roles are granted within one or more projects, project groups, or categories.

The standard CEE roles are as follows, in order of increasing privileges:

• Anonymous Guest
• Registered User
• Observer
• Content Developer
• Developer
• Project Owner
• Domain Admin

(There is also a separate Click-through Viewer role used for a single special purpose as described below.)

Note that a CEE administrator (i.e., someone granted the Domain Admin role) may edit one or more of the standard CEE roles to add new permissions to the role(s), or delete existing permissions from the role(s). However we recommend that you consider creating new roles instead of changing the existing ones. (Among other things, this produces less confusion for users reading standard CEE documentation and training materials.)

Such new roles can be created as domain-wide roles or project roles. Project roles can in turn be visible domain-wide (and hence can be granted in any project) or can be visible only within a particular project or project group (in which case the role can be granted only within that project or its subprojects, or within that project group and projects that are members of that project group).

Anonymous Guest

The Anonymous Guest role is a domain-wide role used for guest users on public CEE sites (i.e., sites that do not require users to register and login). Unlike the other roles described below, it is not necessary to login to a CEE site in order to be associated with the Anonymous Guest role; instead this 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 Anonymous Guest role provides access only to top-level public projects and their public subprojects (or public project groups and public projects that are members of such groups); it is not inherited in private subprojects, so guest users cannot access private projects 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).

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 (top-level) 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.)

 Registered User

The Registered User role is a domain-wide role granted to any registered user on a CEE site (i.e., a user who has been assigned a CEE user-id and, and who logs into the CEE system using that user-id).

The Registered User role provides access only to top-level public projects; it is not inherited in private subprojects, so users cannot access either private projects or “semi-public” subprojects of private projects solely by virtue of being registered users – registered users must have been granted some other role (e.g., the Observer role) to access private or semi-public projects.

Registered users may view documents and announcements in (top-level) public projects, look at public discussion archives, view and check out source code in the version control repository, and query the issue tracking system for issues. Unlike guest users, registered users may also suggest new projects (e.g., using the “Start project” function), submit new issues to the issue tracking system for projects to which they have access, and request to be granted new roles in existing projects to which they have access. Registered users also have a personalized  “My start page”, and may view and edit their own CEE user profile.

Note that a request for a role in a project must be approved by a user who has the Project Owner role (or equivalent) for that project. A request to start a new project must be approved by a user who has the Domain Admin role (or equivalent) for the CEE system.

Click-through Viewer

The Click-through Viewer role is a domain-wide role used solely as part of the user registration process, in order to ensure that newly registered users agree to the site terms of use. (This agreement also known as the “click-through page”, hence the name of the role.)

The Click-through viewer role works as follows: The Click-through Viewer role is associated with one and only one permission, “Click-through Page – Seen”. When a new user is added to the system (either by an administrator or through user self-registration, if enabled) they are immediately granted the Registered User role upon assignment of the user’s CEE user-id; however they are not at that time granted the Click-through Viewer role.

When the new user then attempts to login to the CEE system, CEE checks to see if they have the permission “Click-through Page – Seen” associated with the Click-through Viewer role. Since the user does not have such permission (not having yet been granted the Click-through Viewer role), the CEE system redirects the user to a page on which is displayed the site’s terms of use agreement. If the user reads the page, selects the “Agree” option, and clicks the “submit” button, CEE then grants the Click-through Viewer role to that user. Once that is done, the user can then access the CEE system normally.

(If, on the other hand, the user selects the “Disagree” option and clicks the “Submit” button, they are redirected to the terms of use page once more, and cannot proceed further with CEE until they select the “Agree” option.)

Observer

The Observer role is a project role used for users who are granted “view-only” membership in projects, e.g., the user is to be prevented from changing content in the project’s version control repository.

When a user is granted the Observer role in a particular project, the user will have that (derived) role in all subprojects of that project. Similarly, if a user is granted the Observer role in a project group, the user will have that (derived) role in all projects that are members of that project group.

The permissions granted as part of the Observer role are similar to those associated with the Registered User role: a user with the Observer role in a project can view documents and announcements for the project, look at public discussion archives, view and check out source code in the version control repository, query the issue tracking system for issues, and submit new issues. (Of course, the Registered User role is effective only for public projects, while the Observer role can be granted to a user for any type of project, public or private.) Users with the Observer role can also suggest new projects and request new roles in existing projects.

However a user with the Observer role can perform some additional actions that are not allowed to all registered users: A user with the Observer role can also suggest new project documents and announcements, and can subscribe to and view the archives of discussions associated with the project.

Note that although users with the Observer role may submit new issues to the issue tracking system, they may not add comments to an issue that has already been submitted (whether by themselves or by others). This is because the Observer role does not include the “Project Issue Tracking – Change” permission, which in the standard CEE configuration requires having at least the Developer role.

If you wish to allow users to add comments to issues, but do not wish to grant them the Developer role, then you can edit the standard Observer role to add the “Project Issue Tracking – Change” permission, or you can create a new role based on the Observer role but including that additional permission, and then use that role instead of the Observer role. However note that the “Project Issue Tracking – Change” permission also allows users to change issue milestones, reassign issues, mark issues as resolved, and otherwise make arbitrary modifications to issue data.

Content Developer

The Content Developer role is a project role used for users who are granted permission to modify the web pages associated with the project, but who are prevented from modifying source code and other content in the project’s version control repository.

When a user is granted the Content Developer role in a particular project, then the user will have that (derived) role in all subprojects of that project. Similarly, if a user is granted the Content Developer role in a project group, the user will have that (derived) role in all projects that are members of that project group.

The permissions granted as part of the Content Developer role include all the permissions associated with the Observer role¹. Users having the Content Developer role in a given project can also add new documents to the project file sharing area, and edit existing documents. They can also add and modify content within the “www” directory in the project’s version control repository, i.e., they can do adds, commits, and similar operations against the repository, but only for files and subdirectories within the “www” directory.

This allows users with the Content Developer role to modify the optional project home page (“www/index.html”) and to add other project pages. (Note that in order for the project web page to be used as the default start page for the project, a user with the Project Owner role for the project must edit the project and make sure that the “Use project index.html” checkbox is checked.) However users with the Content Developer role are prohibited from modifying version control content outside the “www” directory; if they attempt to do a commit or similar operation in other directories in the repository, they will get an error message².

Note that although users with the Content Developer role may submit new issues to the issue tracking system, they may not add comments to an issue that has already been submitted (whether by themselves or by others). This is because the Content Developer role does not include the “Project Issue Tracking – Change” permission, which in the standard CEE configuration requires having at least the Developer role.

If you wish to allow users to add comments to issues, but do not wish to grant them the Developer role, then you can edit the standard Content Developer role to add the “Project Issue Tracking – Change” permission, or you can create a new role based on the Content Developer role but including that additional permission, and then use that role instead of the Content Developer role. However note that the “Project Issue Tracking – Change” permission also allows users to change issue milestones, reassign issues, mark issues as resolved, and otherwise make arbitrary modifications to issue data.

Developer

The Developer role is a project role used for users who are granted permission to modify source code, project web pages, and any other content in the project’s CVS repository.

When a user is granted the Developer role in a particular project, then the user will have that (derived) role in all subprojects of that project. Similarly, if a user is granted the Developer role in a project group, the user will have that (derived) role in all projects that are members of that project group.

Users granted the Developer role have all the permissions associated with the Content Developer role; in addition users having the Developer role in a given project can make changes to any file or directory in the version control repository (not just in the “www” directory), and can also make changes to issues already submitted to the issue tracking system.

Project Owner

The Project Owner role is a project role used for users who are granted permission to administer projects.

When a user is granted the Project Owner role for a particular project, then the user will also have that (derived) role in any subprojects created in that project. Similarly, if a user is granted the Project Owner role in a project group, the user will have that (derived) role in all projects that are members of that project group.

A user with the Project Owner role in a project has all the permissions associated with the Developer role, and in addition can perform the following actions within the project:

• Edit the information about the project
• Add, delete, and modify project announcements, and approve project announcements suggested by other users
• Add, delete, and modify project discussions, and subscribe or unsubscribe users to and from discussions
• Configure the project’s issue tracking system (e.g., to define new components and/or subcomponents)
• Administer the project’s version control repository
• Add and delete users from the project’s membership list, and change the roles granted users in the project
• View audit log entries associated with the project

Recall that any registered user may suggest that a new project be created; the request must then be approved by a user with the Domain Admin role (or equivalent). The user suggesting the project is granted the Project Owner role for that project, and may then invite or add additional users to the project as desired.

Domain Admin

The Domain Admin role is a domain-wide role used for users granted permission to administer the overall CEE domain and all projects within it.

A user with the Domain Admin role has the permissions of the Project Owner role for any project created within the CEE system. In addition a user with the Domain Admin role may perform the following actions:

• Add, delete, and edit user-ids, and change users’ passwords
• Add, delete, and edit user groups, including adding and deleting users to and from user groups
• Add, delete, and edit domain-wide and project roles
• Create new projects without needing approval, and approve projects suggested by others
• Lock projects from being used
• Create new project groups and categories, and modify and delete existing project groups and categories
• Display audit log entries associated with all projects
• Display users currently actively using the CEE system

In essence a user with the Domain Admin role can perform all functions that can be performed using the standard CEE user interface. Thus you should grant the Domain Admin role only to a few trusted people.

---

---