Permissions

Edit online

IBM Engineering Lifecycle Management contains two types of permissions: role-based permissions and repository group permissions. Within a project area, you assign role-based permissions for performing operations to individual roles. When you add a user as a member of a project area or team area, you assign one or more roles to the user. By default, team areas inherit permission settings from their parent team areas or project areas. You can customize permission settings within team areas. You can also customize permissions for iteration types, iterations, and timelines.

All users in the repository have the default Everyone role. Even if a user is not a member of a project area, that user has the permissions assigned to the Everyone role for that project area. If you need to restrict users who are not members of the project area from performing certain operations, you must disable that operation from the Everyone (default) role and enable it for one or more other roles.

In addition to role-based permissions, new users are also assigned repository group permissions, which control access to the Jazz repository. Repository group permissions are configured for each user in the user editor.

Roles-based permissions

Role-based permissions are additive, meaning that a user can perform all actions granted to any of their assigned roles. If users are added into Team Areas, to ensure they get restricted access to Team Area you must remove them from the Project Area level.

In the web client, settings for role-based permissions are defined on the Permissions tab of the project area editor. These settings apply to the entire project. To modify permissions for a team area, use the Permissions tab of the team area editor. You can toggle between two views: one that shows permission settings by role, and one that shows permission settings by operation. For example, the following graphic shows the by Operation view.

This image is a screen capture of the Permissions tab of the Project Area editor. It shows two panes. The Select an action pane lists the operations. The Action pane lists the permission settings for each role for the selected operation.

Table 1. Role-based permissions in the project area hierarchy
Location of permission setting	Description
Project area	Permissions at this level apply to the project area and its team areas. Tip: A user who is assigned to a role in a project area has the permissions associated with that role in the project area and in its child team areas, even if the user is not a member of those child areas. For example, a user who has the Team Member role for a project area has the permissions associated with the Team Member role in all child team areas of that project area.
Team area	Each team area can customize the permission settings.
Iteration Types	Permissions at this level apply to all iterations of the iteration type. Each team area can customize the permissions for iteration types.
Timelines	Permissions at this level apply to all team areas in the timeline.
Iterations	Permissions at this level apply to all team areas in the iteration's timeline when the iteration is the current iteration.

At run time, the most iteration-specific permission is used. For example, if you configure permissions for a specific iteration, those permissions are used when that iteration is current. In order from highest priority to lowest, the process run time chooses:

Permissions specified for the current iteration or for the iteration type of the current iteration.
Permissions specified for the parent of the current iteration or for the iteration type of the parent iteration (all the way to the root of the hierarchy).
Permissions specified for the team area timeline.
Permissions specified at the top level of the team configuration of the project area.

Table 2 lists the permissions that you can assign to roles within any Engineering Lifecycle Management project area. For application-specific permissions, see Change and Configuration Management role-based permissions, Engineering Test Management role-based permissions, Requirements Management role-based permissions and Role-based permissions for Global Configuration Management.

Table 2. Role-based permissions that are common to multiple applications
Category	Operation and actions	Description
Dashboards	Save Personal Dashboard Create a personal dashboard Delete the personal dashboard Modify the personal dashboard	Create, modify, and delete personal dashboards.
	Save Project Dashboard Create a project dashboard Delete the project dashboard Modify the project dashboard	Create, modify, and delete the project dashboard.
	Save Team Dashboard Create a team dashboard Delete the team dashboard Modify the team dashboard	Create, modify, and delete team dashboards.
Item Connectors	Delete Synchronization Rule Info Delete external repository connection Delete synchronization rule	Delete an external repository connection. Delete a synchronization rule.
	Save Synchronization Rule Info Create external repository connection Create synchronization rule Modify external repository connection Modify synchronization rule	Create or modify an external repository connection. Create or modify a synchronization rule.
	Synchronize with External Objects Apply incoming changes Initiate outgoing synchronization Save external data Apply outgoing changes Initiate outgoing synchronization Create connection Delete connection Update synchronization status	Manually initiate an incoming synchronization operation (to retry after an error, for example). Save incoming data from an external object to the repository. Manually initiate an outgoing synchronization operation (to retry after an error, for example). Create a new connection between an external object and an object in the repository, so they can be synchronized. Delete an existing connection between an external object and an object in the repository, so they are no longer being synchronized. Modify the status of the connection between an external object and an object in the repository.
Process	Generate Team Invitation	Generate an E-mail message that informs a users that they have been added to a team area or project area.
	Save Process Description Create a process description Delete the process description Modify the process description	Create a process description for a project area or a process template. Delete a process description for a project area or a process template. Make changes to a process description for a project area or a process template.
	Save Project Area Archive a project area Archive elements in the iteration structure Archive a timeline and all its iterations Archive an iteration and all its child iterations Modify a project area Modify project area properties Modify the collection of process attachments Modify the collection of team members Modify the iteration structure Modify the process specification	Remove a project area from most parts of the user interface by archiving it. Archive a timeline. Because iterations belong to a timeline, when you archive a timeline, all of its iterations are also archived. Archive an iteration. If the iteration contains child iterations, all of those child iterations are also archived. Make changes to the project area that are not governed by another action. This includes changes to the following: project area name, summary, or description; project area associations; process sharing; and process description of a project area in the Overview tab in the IBM Engineering Workflow Management client for Eclipse IDE. It also includes specifying the timeline for a team area. Add, remove, or modify process attachments on the project area. Add and remove users as members of the project area. Assign roles to members. Modify the iteration structure. This includes changing timelines; setting an iteration as the timeline’s current iteration; changing an iteration; and adding, removing, or modifying child iterations. Modify the process specification. This includes, for example, changes to role definitions, permissions assigned to roles, operation behavior (preconditions and follow-up actions), iterations, configuration data, and project area initialization.
	Save Team Area Archive the team area Create a team area Modify a team area Modify the collection of process attachments Modify the collection of team members Modify the process customization Modify the team area properties Remove a team area	Remove a team area from most parts of the user interface by archiving it. Create a team area. Add, remove, or modify process attachments on the team area. Add and remove users as members of the team area. Assign roles to members. Customize the process for the team area. Customizing the process for a team area can involve overriding settings that the team area inherits from its parent team area or project area. Make changes to the team area that are not governed by another action. For example, the name, summary, or description. Remove a team area.
Reports	Deploy Report Create Report Delete Report Modify Report Set Default Team Report	Create a shared (non-private) report. Delete a shared (non-private) report. Modify a shared (non-private) report. This usually means that the user is attempting to change the parameter values that are stored with the report. Make a report the default report for a team area.
	Deploy Report Resource Create Report Resource Delete Report Resource Modify Report Resource	Create a report resource on the server. Delete a report resource from the server. Change any attribute of an existing report resource, such as the name, description or sharing information. Upload new design content for that resource.
	Display Report	Render a report. This can happen when viewing a report in the client and also occurs when reports are included in other contexts (for example, the Dashboard).
	Manage Report Folder Create Folder Delete Folder Modify Folder	Create a shared (non-private) report folder. Delete a shared (non-private) report folder. Change any attribute of an existing shared (non-private) report folder, such as the name, description or sharing information.
Work Items	Delete Query	Delete a query.
	Delete Work item	Delete a work item. The user must also be a member of the JazzAdmins or JazzProjectAdmins repository group.
	Export Query Export Query Result	The Export Query operation is executed when the data is exported. Grants the user permission to export query result.
	Save Attachment Delete Attachment Modify Attachment	Delete a work item attachment. Make changes to a work item attachment.
	Save Category	Make changes to a work item category.
	Save Enumeration	Create an enumeration attribute.
	Save Query Modify a query Modify other query attributes Modify the query conditions Share or unshare a query	Modify query attributes other than the query conditions and whether it is shared. Modify the query conditions, which are the selection criteria. Modify whether the query is shared or private.
	Save Release	Create or modify a release.
	Save Work Item Bulk work item operation Create a work item Import a work item Modify the work item Modify the work item’s approvals Setting up work item approvals Remove work item from team area Trigger a workflow action	Perform operations on more than 20 work items at a time. Bulk work item operations let you assign the same field value to many work items at once. Create a work item. You can grant this permission for each work item type, such as Defect, Task, and so on. Create work items by importing attributes from a comma-separated value (CSV) file. Make changes to a work item. You can grant this permission for each work item attribute. In this way, you can control which fields a role can change. Tip: If a user changes the value of the Filed Against attribute so that the work item is associated with a different team area, the role-based permission settings for that team area are in effect. Because permission to modify work items can be set for each attribute, the user might not be allowed to save work items after changing some attributes. Modify the state of work item approvals. Create, update, and delete work item approvals. Tip: A user whose role does not have permission to modify the Planned For attribute can do so if they also modify the Category (Filed Against) attribute, which is associated with a team area. Move a work item to a different team area or project area. Note: The creator of the work item can perform this action even if they do not have a role that has this permission. Trigger a workflow action, which transitions a work item from one state to another. You can grant this permission for each transition action.

Repository group permissions

When creating a user, you assign repository group permissions. Repository group assignments control user access to the Jazz repository. Assign one or more of the following groups for a new user:

Table 3. Repository group permissions
	JazzGuests	JazzUsers	JazzProjectAdmins	JazzAdmins
Read access to repository	Yes	Yes	Yes	Yes
Write access to repository		Yes	Yes	Yes
Control the data warehouse				Yes
Create and modify process templates			Yes	Yes
Create project areas			Yes	Yes
Modify access control settings for project areas			Yes	Yes
Save project areas			Yes (see note below)	Yes
Generate team member invitations			Yes	Yes
Create users				Yes
Configure the server				Yes

Each project area, through its access control settings, can restrict read access to specific users. Users who have at least JazzUsers repository group permissions and have read access to a project area can perform the actions granted to the role or roles assigned to them within that project area. See Table 2 for the list of role-based permissions.

Note: JazzProjectAdmins users can save project areas regardless of the role permission settings in the project areas, if they created the given project area or if they are the administrators of those projects. This includes the ability to generate team member invitations. This override ability does not extend to project areas to which the user does not have read access.

Tip: The JazzProjectAdmins permission is intended for users who need to create project areas. The project administrator of a project area does not need JazzProjectAdmins permission to manage that project area. Within a project area, a user who is designated as Administrator has read-write access for that project area.