JIRA Fields Synchronization
JIRA issue fields must be mapped to Codebeamertracker fields.
The following JIRA issue fields are always synchronized implicitly according to the synchronization direction:
• Id
• Key
• Summary
• Description
The attachments on a JIRA issue are synchronized by default, but can be changed, if necessary. All other JIRA issue fields must be manually mapped to tracker fields.
Only the fields on the Create Issue screen for the selected JIRA Project and Issue Type are available for synchronization. In case of a missing field, check the appropriate Create Issue screen configuration in JIRA.The following JIRA issue fields can only be imported in to Codebeamer.
• Creator
• Created
• Updated
JIRA automatically sets these fields to the current user and current date when the issue is created or updated. These field values cannot be otherwise changed.
The same restrictions apply to the JIRA change log. Codebeamer can read and import the JIRA change log, but cannot write or export its own change history to JIRA.
Each field listed in the Fields section, can be configured to:
• Ignore Values—Ignore the value for this field.
• Import Values—Import the values from JIRA toCodebeamer
• Export Values—Export the value from Codebeamer to JIRA.
• Synchronize Values—Synchronize the value between JIRA and Codebeamer bi-directionally.
 | Values of JIRA fields which are not editable by the specified user can only be imported. |
| | Values of Codebeamer fields which are not editable. for example, fields with computed values can only be exported. |
Mandatory fields in JIRA are marked with an asterisk.
Exporting new Codebeamer tracker items to JIRA, that is creating a new jira issue. without mapping the mandatory fields to Codebeamer tracker fields,exporting/synchronizing the Codebeamer field value to JIRA, likely fails, unless the JIRA field has a default value.
The field value synchronization mode is not restricted by the currently selected synchronization Direction. This is because the configuration of the field value synchronization can be changed to Export or Bi-directionally even if the current Direction field value is Import Only, or vice versa. This way, there is no need to adjust all field synchronization modes every time the synchronization direction is changed.
| | Field are only synchronized when the field synchronization mode points into the actual synchronization direction, that is , an import followed by an export. |
For JIRA picker fields, the choice values also need to be mapped to the Codebeamer ALM's choice options. Missing choice options can be created using the New... option from the dropdown list.
For example:
The following image shows the bi-directional mapping between the Status field in JIRA and the Status field in Codebeamer
When creating new Codebeamer status options consider the following:
• Tracker fields can have specific permissions and allowed values for each status. Such fields do not allow values and permission for the newly added status. As a result, these fields may not be visible or editable for imported items with this status.
• If the tracker workflow is active, no state transitions lead in or out of the newly added status. Imported items with this status are not able to proceed in the workflow unless the new status is connected using newly defined state transitions.
The JIRA connector does not modify the existing Codebeamer state transitions unless the following conditions are met:
• The synchronization direction is Export or Synchronize.
• The JIRA Status field is mapped to the Codebeamer Status field.
• The Codebeamer Status values are Exported or Synchronized to JIRA.
The workflows are only synchronized by replacing the Codebeamer workflow with the JIRA workflow if one of the following are true:
• The user has JIRA System Administrator permission.
• The user synchronizes the workflows manually.
If multiple JIRA choice options are to be mapped to new target choice options, new target options can be created for all of them by clicking on the downward arrow icon next to the JIRA choice field name:
JIRA fields to import and synchronize that do not have an appropriate counterpart in the Codebeamer tracker can be added based on the JIRA field definition. To perform this action, click on New... in the dropdown list.
For example to create a new tracker field in Codebeamerfor the JIRA Component/sfield, click New... in the dropdown list for the field.
You can accept the name of the JIRA field for the new Codebeamer tracker field, or enter a different name:
The name must be unique across all tracker fields, and not only for the current tracker field. If there is a name conflict, enter a different name
The following fields cannot be mapped to new custom fields, but only to their predefined targets:
• Creator
• Created
• Updated
• Sprint
• Roles
• Attachments
• Comments
• Worklog
• Change Log
JIRA Agile Fields, such as, Sprint and Epic Link, can be synchronized.
Because there are not any pre-defined Codebeamer Epic reference fields, therefore, a new target field must be defined for the JIRA Epic field.
• If Epic linking is enabled, the target tracker field is a reference field to the imported Epic work item.
• If Epic linking is disabled, it behaves like a text field which only contains the key of the JIRA Epic.
The JIRA Sprints field can either be ignored or imported as Sprints.
In Codebeamer:
• Both the Releases and Sprints field are configuration items of the Releases type in the Releases tracker, where
◦ Releases are the top-level items, and Sprintsare typically children of releases or other sprints.
• The Release and Sprint planning enables assigning work items to releases and sprints using the predefined target Versionsreference field This field label can be different, for example, Releases.
In JIRA:
• Both versions and sprints are different entities and are associated with issues using different reference fields:
◦ Versions are associated with issues using the Fix Version/s field.
◦ Sprints are associated with issues using the Sprints field.
• Sprints are not related to versions.
InCodebeamer Release and Sprint planning work with imported JIRA issues if both the JIRA versions and JIRA sprints are imported into the same Codebeamer Releases tracker and both are associated with work items using the same target versions field.
Since there is no relation between sprints and versions in JIRA, sprints are imported as top-level items in Codebeamer. There are no extra sprints fields in the target Codebeamer tracker. Sprints are only an alias for all work items that represent imported JIRA sprints and that are associated with the tracker item using the target versions field.
At the bottom of the Fields list, choose whether to ignore, import, export, or synchronize the fields.
The Roles mapping is primarily for synchronizing fields of the Role(s) type and comments visibility that is based on the roles. Jira can restrict comment visibility to a single role or group. Codebeamer can restrict comment visibility to multiple roles and participants using member fields such as Submitter, Assigned To, and Owner. The only common restriction that can be synchronized is a single role.
| | Creating a new target role only creates an appropriate role stereotype or value, in the target Codebeamer project, not an actual role. |
In JIRA, the size of issue attachments is limited.
When configuring synchronization of attachments by exporting from JIRA, the JIRA administrator needs to check or adjust, the issue attachment size limit.
| | Comments, Worklog, and Change Log can be synchronized only if Users are synchronized. |
The Worklog is imported as the item of the Timekeeping tracker within the Codebeamer project, and is shown as the Time Recordings for Subject field under the References of the imported issue.
If the JIRA Change Log is imported as History field for the Codebeamer issue, only mapped fields that are related to Change Log entries are imported. Entries such as Project, Key, Workflow, and Labels are ignored.
JIRA Change Log entries related to Comments, Attachments, Issue Links and Work Log that have no equivalent in Codebeamer or are handled, and stored differently.
Codebeamer can only read or import the JIRA Change Log Codebeamer cannot write and export its own change history to JIRA.
This also affects the exporting of issues, issue changes, attachments, comments, and worklog entries from Codebeamer to JIRA. The export is executed as by the JIRA user specified in the JIRA Synchronization Settings. All exported issues, issue changes, attachments, comments, and worklog entries are associated with this user in JIRA, and not with the user that originally created the issue, issue change, comment, or worklog entry in Codebeamer.