Login | Join Now
  • Organizing and Controlling Access to CEE Projects

    Product:
    CollabNet Enterprise Edition


     
    Related Links
    CEE

    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

    Conclusion



    We have now completed our overview of the various CEE features to organize projects and control access to them, and have given a number of examples of how these features can be used. The following summarizes the key features of CEE in this area:

    • Every CEE user is typically assigned an individual user-id (except for the special case of guest users accessing public CEE sites as noted below).
    • CEE users can be granted roles in one or more CEE projects, with each such role providing a particular set of permissions with respect to a project’s file sharing area, version control repository, discussions, issue tracking system, etc. Different users can be granted different roles.
    • CEE provides a number of pre-configured roles to correspond to particular standard sets of permissions; such standard roles include the Observer role, the Content Developer role, the Developer role, and the Project Owner role.
    • Resources can be used to provide finer-grained control over access to a project’s version control repository, and are used, for example, to distinguish between the Developer role and the Content Developer role.
    • When multiple projects are unrelated to each other and do not have users in common (for the most part), you can organize them as independent top-level projects.
    • When multiple projects are part of a larger initiative and may share similar needs for access control, you can organize them as subprojects of a single parent project. With certain exceptions as noted below, a user’s role in a parent project is inherited in subprojects of that project.
    • When identifiable sets of users participate in multiple projects, you can define user groups containing user-ids for each respective set of users, and then grant a role to a user group instead of individual user-ids. Users then have roles in the project based on the role granted to their user group. Users may belong to more than one user group.
    • When a group of users needs access to an otherwise independent set of projects, you can create a project group of which the projects are members, and grant the users (or a user group containing the users) a role in the project group; the role will be inherited in projects that are members of the project group. A project may be a member of more than one project group, and may be a member of a project group in addition to being a subproject of a parent project.
    • A project role that a user has inherited from a parent project (or a project group), or that a user has by virtue of being in a user group, is a derived role, as opposed to a direct role that is explicitly granted to the user’s user-id in the project in question. A user is not considered to have joined a project unless their user-id has been granted a direct role in that project.
    • Projects can be either private or public. Any logged-in user can access top-level public projects and their public subprojects, using the Registered User role. However the Registered User role is not inherited in private subprojects of public projects.
    • A CEE system can be a public site, allowing guest users access to the site without having to login, using the Anonymous Guest role. Like the Registered User role, the Anonymous Guest role is not inherited in private subprojects of public projects.
    • You can use categories to group projects together to help users discover projects of interest to them. Like projects, categories may be public or private; private categories are made known only to users granted at least the Observer role (or equivalent role) in the category. Categories may contain public or private projects; a user viewing a category will not see private projects in a category unless the user has roles (direct or derived) in those projects.

    Because of the many CEE features relating to access control and project organization, and the many ways in which those features can interact, we recommend that you take the time to plan out the ways in which you plan to organize your projects and users; you may also wish to experiment with test projects and test users to ensure that the permissions for users are configured as you intended.