TeamForge 16.3 does not have fine level controls with regard to project functions as a project-level role. However, project operations are a part of a site-wide role. Hence the mapping is done to site-wide roles, except for project administrator.
Permission Mapping Details
| CollabNet Enterprise Edition Permission | TeamForge 16.3 Permission | Change in Behavior | Functionality Loss/Gain Details | Comments |
|---|---|---|---|---|
| Project - Associate Project | User loses permission | The user loses the ability to map project to a category/project group | TeamForge 16.3 allows only project administrators to do so, which is way above this permission. | |
| Project - Associate With Project | User loses permission | The user loses the ability to map project to a category/project group | ||
| Project - Delete | Projects: Delete/View, Categories: Delete/View | User loses permission | The user loses rights to delete project if the role is project-level/Global | Conditional mapping. This permission is granted only if the role is a site-wide role. |
| Project - Designate Subproject | User loses permission | The user loses the ability to set parent-child relationships between projects | TeamForge 16.3 allows project administrators to set parent-child relationships. | |
| Project - Designate Superproject | User loses permission | The user loses the ability to set parent-child relationship between projects | TeamForge 16.3 allows project administrators to set parent-child relationships. | |
| Project - Edit | Project Admin: Project Admin Permissions, Project Pages: Project Pages Admin | User gains permission | The user gains other project administrator capabilities like setting parent-child relationship etc. | Mapping is done to PCE also since it is a project administrator's responsibility to configure PCE pages. |
| Project - Invite | This feature is not available in TeamForge 16.3 | TeamForge 16.3 does not have any such feature. | ||
| Project - Lock | The user loses the ability to lock/unlock projects | Project administrators can do this in TeamForge 16.3. | ||
| Project - View | Projects: View Only | CollabNet Enterprise Edition permission is retained | Conditional mapping. The proposed mapping is done when the role is a domain role. For project/global project roles, user will have the view access just by the role assignment. In the case of a role project/global project role with just this permission, the users belonging to the role are added as a member of the project in case of private projects. | |
| Project Content - View | User gains permission | Without having such a permission, users will gain access to remote published contents. | TeamForge 16.3's remote publishing implementation needs only "View" access to the project. | |
| Project Member - List | This feature is not available in TeamForge 16.3 | TeamForge 16.3 does not have any such feature. | ||
| Project Page - View | Projects: View Only | User gains permission | Exact changes not clear | Conditional mapping. The same approach as that of "Project – View" permission is followed. There is no clear separation of responsibilities between "Project – View" and "Project Pages – View". In TeamForge 16.3, these are merged. |
| Private Project Document - View | CollabNet Enterprise Edition permission is retained | |||
| Project - Site-specific | User gains permission | The user will lose the ability to control access to site specific contents. Users will see all project content if the user gets permissions to the project. | TeamForge 16.3 does not have any such feature. |