You are not logged in. Click here to log in.

codebeamer Application Lifecycle Management (ALM)

Search In Project

Search inClear

Synchronizing Trackers with Atlassian JIRA©

Since codebeamer release 9.0, synchronization (Import and/or Export) is available between Intland codebeamer and Atlassian JIRA© on tracker level.

Prerequisites

The synchronization requires the JIRA© Server REST API (Version 2). JIRA© Server 6.3.8 and newer should work, older versions have not been tested.

Synchronizing Trackers with Atlassian JIRA© Cloud is only supported in codebeamer 9.4 and newer.

In case codebeamer release 9.3 or older had been used to synchronize trackers with JIRA© Cloud (which is not working any more, due to changes in the JIRA© Cloud REST API), and the synchronization is intended to be continued with codebeamer release 9.4 and newer, follow the Migration Steps described in Synchronizing Trackers with Atlassian JIRA© Cloud.

Synchronization with Jira Server 9.0 is supported since codebeamer 21.09-SP12 (EMMA).

The Get create issue meta endpoint of the JIRA REST API V2 has been deprecated in JIRA Server 8.4 REST API, and removed from JIRA Server 9.0 REST API.

Synchronizing with JIRA Server 9.0 and newer:

  • Both synchronization end-points:
    • the codebeamer Tracker Type,
    • and the JIRA© Project and Issue Type
      must already exist.
  • codebeamer can only adjust its own configuration to JIRA's configuration, but not vice versa.


  • There is no restriction on the type of JIRA issue types that can be associated with trackers of a specific type, however, the below mapping could be considered default:


codebeamer Tracker Type JIRA Issue Type
Bug Bug
Task Task
User Story Epic or Story
Requirement Requirement
Change Request New Feature or Improvement


Individual trackers cannot be synchronized in projects which had been imported from Atlassian JIRA© via Importing Projects from Atlassian Jira. This also applies to trackers of type
  • Release
  • Component
  • Pull Request
  • Test Run
  • Time Recording

JIRA Synchronization Settings

To synchronize a tracker with JIRA, go to the relevant tracker's (more) context menu ► Synchronize with JIRA.


In case the current tracker has not yet been associated with any JIRA Project and Issue Type, codebeamer offers to perform the configuration. Click on [Yes] to proceed.

Tracker Admin permission is required for the user to perform the configuration.



One-To-One JIRA Synchronization

1. To log in, provide the

  • Web-Address (hostname, IP-address and port) of the remote Atlassian JIRA© Server
  • Username
  • Password

If the Server is a JIRA© Cloud instance (https://instance.atlassian.net), use the below credentials:


2. Select the relevant JIRA© Project and Issue Type in the Issues field to associate with the current tracker:


  • The specified JIRA user needs to have at least the Browse projects permission for the selected JIRA project in order to continue with the synchronization
  • JIRA does not have an issue hierarchy. There can be so-called Sub-Tasks, but those are issues with a different issue / sub-task type.
    • Sub-Tasks of the selected issues are not imported to / synchronized with codebeamer.
    • codebeamer 9.0 and older - only the top-level items in the codebeamer Tracker are exported / synchronized to JIRA, descendants are not.
    • Since codebeamer 9.1 - all items in the codebeamer Tracker are exported / synchronized to JIRA as a flat issue list (no parent / child relationship in JIRA).

One-To-Many JIRA Synchronization

Since codebeamer release 22.10-LTS (GINA), multiple JIRA instances can be synchronized with a single codebeamer user on Tracker level.


To open the JIRA Synchronization Settings overlay, click on the (more) context menu of the relevant tracker ► Synchronize with JIRA.


  • A combo-box has been added to the JIRA Server field to choose from the different instances available by clicking on the downward arrow.
  • To record new instances, click on the (Edit this JIRA Server) icon and provide the relevant Username and Password.
    A Description field has also been added to the JIRA Server overlay for further, optional notes.


After imports, JIRA users are mapped to the proper codebeamer users.


After exports, codebeamer users are mapped to the correct JIRA users of the target JIRA server.

JIRA Synchronization Direction

The default synchronization Direction is Import Only.

Further options are

  • Export Only
  • Synchronize Bi-directionally





    By default, the synchronization (in the specified direction) is Enabled. Deselect the checkbox to disable it.



JIRA References Synchronization

Before mapping fields of the JIRA Create/Edit issue screens with codebeamer Tracker fields, specify how to handle certain JIRA issue references:





By default:

  • User and Group references are only imported as User and Group names.
  • Version and Component references are imported as static choice field options.
  • Team references (since codebeamer 9.3) are imported as static choice field options.
  • Epic links (since codebeamer 9.3) are imported as JIRA Epic keys.


In order to map the JIRA issue Reporter/Assignees to the Owner/Assigned to attributes of the codebeamer item, enable Users import (requires codebeamer User Admin permission):

  • All JIRA Users referenced by imported JIRA issues, where no appropriate codebeamer user (with the same name or email address) exists, are created as codebeamer users.
  • Only the below user attributes are imported:
    • user name
    • first/given name
    • last/family name
    • email address
    • avatar/picture
  • All imported users are initially disabled
    • as their password cannot be imported, and has to be reset manually before such a user can log into codebeamer.
    • to not exhaust the available number of codebeamer user licenses.
  • codebeamer tracker items cannot be assigned to disabled users, or to non-project members.
    • To assign codebeamer items to imported JIRA users,
      • activate the imported users first,
      • and assign the users roles in the codebeamer project.
  • Since this synchronization is on tracker level, the imported users are not members of the codebeamer Project.
  • Updating a user in JIRA only updates the appropriate codebeamer user if that user was originally imported from JIRA.
  • Deleting a user in JIRA which was previously imported to codebeamer does not delete that user in codebeamer, as deleting users in codebeamer is generally not possible.
  • Modifying a user in codebeamer which was imported from JIRA does not synchronize those changes back to JIRA.


The Submitted at and Last Modified at dates of the codebeamer item also depend on the Users handling. Import the Submitted at field only if the Submitted by field is imported as well.



In order to map the JIRA issue Affects Versions / Fix Versions to the Detected in / Release attributes of the codebeamer item, enable the Versions import:

  • JIRA Versions are imported as items of the Releases tracker in the current project.
  • Modifications of JIRA Versions (Create, Update or Delete) are synchronized with codebeamer.
  • Modifying imported Releases in codebeamer, or adding new Releases in codebeamer are not synchronized back to JIRA, but remain private to codebeamer.


In order to refer to JIRA components as codebeamer config items, enable Components import:

  • JIRA Components are imported as items of the Components tracker in the current project.
  • Modifications of JIRA Components (Create, Update or Delete) are synchronized with codebeamer.
  • Modifying imported Components in codebeamer, or adding new Components in codebeamer are not synchronized back to JIRA, but remain private to codebeamer.


In order to map the JIRA issue Team field to the Team field of the standard item of codebeamer, enable Teams import (since codebeamer 9.3.):

  • Teamsimport is only available if the JIRA issue type to synchronize has
    • a JIRA PortfolioTeam field which refers to Portfolio Teams
    • or a custom (multiple) choice field with the name Team or Teams the choice options of which are the defined Teams.
  • JIRA Teams are imported as config items into the Teams tracker in the current project.
  • Modifications of JIRA Teams (Create, Update or Delete) are synchronized to codebeamer.
  • Modifying imported Teams in codebeamer, or adding new Teams in codebeamer are not synchronized back to JIRA, but remain private to codebeamer.


In order to refer to JIRA Epics as codebeamer work items (since codebeamer 9.3.), enable Epics linking:

  • Epics linking can only be enabled if the issue type Epic of the JIRA project is synchronized with an appropriate Epic tracker type in the codebeamer project.
  • There is no pre-defined codebeamer Epic reference field, therefore a new/custom target field needs to be defined for the JIRA Epic Link field.

JIRA Fields Synchronization

JIRA issue Fields need to be mapped to codebeamer Tracker fields.

The JIRA issue

  • Id
  • Key
  • Summary
  • Description

are always synchronized implicitly according to the synchronization Direction.


The JIRA issue Attachments are synchronized by default, but can be changed, if necessary. All other Fields must be mapped to Tracker Fields manually.

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 values of the JIRA issue

  • Creator
  • Created
  • Updated

fields can only be imported into codebeamer.'

JIRA automatically sets these fields to the current user and current date upon issue creation or issue update, and does not allow to amend these field values otherwise.

The same restrictions applies to the JIRA Change Log: codebeamer can read/import the JIRA change log, but cannot write/export its own change history to JIRA.

For each field, it can be configured whether to:

  • Ignore field
  • Import Values - JIRA codebeamer
  • Export Values - JIRA codebeamer
  • Synchronize Values - JIRA codebeamer (bi-directionally)



Values of JIRA fields which are not editable/writable (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 (Create a new JIRA issue)

  • without mapping the mandatory fields to codebeamer tracker fields,
  • or, without exporting/synchronizing the codebeamer field value to JIRA,

most probably fails, unless the JIRA field has a default value.


The field value synchronization mode is not restricted by the currently selected synchronization Direction:

  • The configuration of the field value synchronization can be changed to Export or Bi-directionally even if the current Direction 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.
Only those fields are synchronized where the field synchronization mode points into the actual synchronization direction, therefore, an Import followed by an Export.



For JIRA picker fields, choice values also need to be mapped to codebeamer ALM's choice options. Missing choice options can be created via New... ,if necessary.


For example:


JIRA Status codebeamer Status



When creating New codebeamer Status options:

  • Tracker Fields can have specific Permissions and Allowed Values per Status.
    • Such fields do not allow values and permissions for the newly added Status, therefore, these fields may not be visible/editable for imported items in this Status.
  • If the Tracker Workflow is active,
    • No State Transitions leads in or out of the newly added Status.
    • Imported items in this Status are not able to proceed in the workflow unless the newly added Status is connected via newly defined State Transitions.


The JIRA connector does not modify the existing codebeamer State Transitions, unless:

  • the synchronization direction is Export or Synchronize, and
  • the JIRA Status field is mapped to the codebeamer Status field, and
  • the codebeamer Status (values) should be Exported or Synchronized to JIRA.

Then, the workflows is only synchronized (by replacing the codebeamer workflow with the JIRA workflow, see below), if

  • the user has JIRA System Administrator permission, or
  • 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:




Fields to import/synchronize that do not have an appropriate counterpart in the codebeamer Tracker can be added based on the JIRA field definition. Click on New...


Example: Create a new field for Component/s:





Adopt the name of the JIRA field for the new codebeamer tracker field, or use a different name:




Even if the target selector does not show a field with the specified name, you can still get a name conflict because each target field selector only shows those existing tracker fields which are assignment compatible to the JIRA field but the new field name must be unique for all tracker fields! In that case, try another name.


Depending on the nature/meaning/type of a field, 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.



In codebeamer 9.2 and older, only JIRA Core Fields can be synchronized. Fields defined by JIRA plugins and extensions (for example, Epic links from JIRA Agile) are not available for synchronization.



Since codebeamer 9.3, JIRA Agile Fields, (for example, Sprint and Epic Link) can be synchronized:



There are not any pre-defined codebeamer Epic reference fields, therefore, a new/custom target field needs to be defined for the JIRA Epic Link field.

  • If Epics linking is enabled, the target tracker field is a reference field to the imported Epic work item.
  • If Epics linking is disabled, it behaves a text field which only contains the key of the JIRA Epic.


The JIRA Sprints can either be ignored or imported as Sprints.

In codebeamer:

  • Releases and Sprints are both config items of type Release in the Releases tracker, where
    • Releases are the top-level items, and
    • Sprints are typically children of Releases or other Sprints .
  • The Release and Sprint planning assign work items to releases and sprints only via the predefined target versions reference field (the field label can be different, for example, Release):

In JIRA:

  • Versions and Sprints are different entities and are associated with issues via different reference fields:
    • Versions via Fix Version/s
    • Sprints via Sprint
  • Sprints are not related to Versions.

codebeamer 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;
    • since there is no relation between Sprints and Versions in JIRA, imported Sprints are top-level items in codebeamer.
  • are associated with work items via the same (target) versions field.
    • There are no extra Sprints field 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 via the (target) versions field.

At the bottom of the Fields list, choose whether to

  • Ignore
  • Import
  • Export
  • Synchronize

The Roles mapping is primarily for synchronizing

  • Fields of type Role(s)
  • Comments visibility is based on Role(s):
    • JIRA can restrict comment visibility to a single role or group.
    • codebeamer can restrict comment visibility to multiple roles and/or participants (member fields, for instance, Submitter, Assigned To, Owner).
    • The only common restriction that can be synchronized is a single role.
Creating a new target role only creates an appropriate role stereotype/value, and not an actual Role in the target codebeamer project.



In JIRA, the size of issue attachments is limited.
When configuring to export or synchronize Attachments, the JIRA administrator needs to check or adjust, if needed the issue attachment size limit.

Comments, Worklog and Change Log can only be synchronized if Users are synchronized.
The Worklog is imported as the item of the Timekeeping tracker within the codebeamer Project, and is shown as Time Recordings for Subject under the References of the imported issue.

If the JIRA Change Log is imported as codebeamer issue History, only mapped Fields related Change Log entries are imported.

The following entries are ignored:

  • Project
  • Key
  • Workflow
  • Labels
  • etc.

There are JIRA Change Log entries related to Comments, Attachments, Issue Links and Work Log that have no equivalent in codebeamer (Work Log) or are handled, stored differently.


codebeamer can only read/import the JIRA Change Log. Writing/exporting its own change history to JIRA is not possible.


This also affects the export of issues, issue changes, attachments, comments and worklog entries from codebeamer to JIRA:

  • The export is executed as specified by the JIRA user 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 (change), comment or worklog entry in codebeamer.



JIRA issue Links can be mapped to codebeamer Associations based on the link type:





Configurations available for link types:

  • Ignore (not import) links of this type
  • Import links of this type - JIRA codebeamer

In codebeamer 9.3 and older, the configure below configuration options are erroneously allowed:

  • Export links of this type - JIRA codebeamer
  • Synchronize links of this type bi-directionally - JIRA codebeamer

Exporting codebeamer associations to JIRA is not supported.



JIRA Synchronization Interval and History

The JIRA synchronization can be configured to run automatically in the background (for example, every 4 hours):





The smallest allowed synchronization Interval is the last 10 minutes.

If the synchronization runs frequently, limit the size of the synchronization History, for example, to only keep the last 100 synchronizations.

The first synchronization always needs to be started manually as additional manual Tracker Customizationsmay be necessary:
  • State Transitions(only if workflow has been synchronized with JIRA, see below),
    • Permissions (imported transitions are granted to everybody),
    • Actions
  • Fields (only if new custom fields have been added)
    • Allowed/Default values
    • Mandatory (in status)
    • Permissions (imported fields are initially unrestricted).
    • Distribution/Aggregation rules



Re-Using JIRA Synchronization Settings

To re-use the JIRA Synchronization Settings of a tracker (as a template) for other tracker synchronizations,

  • Save a configuration as a configuration file by clicking on Save as.
  • Later, load this configuration file when configuring another tracker synchronization by clicking on Load from file..
    • Loading a configuration from file overwrites the actual settings. It is advised to use this option at the beginning.





Removing JIRA Synchronization

In codebeamer 9.0 and older, JIRA synchronization cannot be removed from a tracker once it had been configured.

The only way to re-assign a JIRA project and issue type which was previously associated with a tracker, was to irreversibly delete

  • the associated tracker
  • or the whole project, where associated tracker belonged to.

Since codebeamer 9.1, JIRA synchronizations can be removed from a tracker by clicking on Remove... in the JIRA synchronization settings.

This is also an irreversible process that deletes

  • the JIRA synchronization settings of the tracker,
  • the JIRA synchronization history of the tracker,
  • the JIRA synchronization job/schedule of the tracker,
  • the JIRA synchronization information of all synchronized tracker items in this tracker, including the JIRA ID and the JIRA Key attributes.

When removing JIRA synchronizations, the tracker itself, the tracker configuration and also the tracker items are kept.


Tracker items synchronized previously with JIRA are no longer recognized as such.
  • If other JIRA issues are imported later into a different tracker, that have links to JIRA issues that were previously represented by items in this tracker, the newly imported items do not refer to any items in this tracker.
  • If JIRA synchronization is set up later for the same tracker again (perhaps even associated with the same JIRA project and issuetype than before):
    • importing does not update any existing tracker items but creates new items for all JIRA issues instead.
    • exporting exports all existing items as new JIRA issues, and does not update any existing JIRA issues.


To disable the JIRA synchronization without losing any synchronization settings, history and status, deselect the Enabled checkbox. This can be re-enabled any time.


Since codebeamer 10.0, a Tracker Synchronization Listener can be implemented and deployed in order to be notified whenever a Tracker is attached/detached with JIRA, or, the JIRA Synchronization Configuration changes.


JIRA Workflow synchronization

If the JIRA Issue Status field is mapped to the codebeamer Tracker Item Status field (export or bi-directionally),

  • the JIRA Issue Resolution field needs to be mapped to an appropriate codebeamer Tracker Item field, and that field value also needs to be synchronized with JIRA.
  • the codebeamer State Transitions must be synchronized with the JIRA issue workflow, otherwise, exporting codebeamer status changes to JIRA may not be possible.
Only map the JIRA Issue Status field to the codebeamer Tracker Item Status if the codebeamer tracker should fully adopt the JIRA Workflow.
If JIRA should not be the Master for the Workflow,
  • either avoid the mapping of Status,
  • or import the JIRA Statusto a new custom tracker field (for example: "JIRA Status"):
    • only if synchronization is required between codebeamer Status and JIRA status (at specific synchronization points).
      • configure actions in the appropriate codebeamer State Transitions or workflow Event Handlers that change the JIRA Status accordingly.


If the JIRA user configured for the JIRA synchronization has Administer projects permissions on the JIRA project, codebeamer performs the necessary JIRA issue workflow synchronization automatically.

Otherwise, the workflow synchronization is to be performed manually:




After selecting the

  • Change the user for the JIRA synchronization, or to
  • Synchronize the workflow with a one-time login as a different user,

the username and password of a JIRA user need to be entered (Administer projects permissions on the JIRA project required).





Without the access, the workflow can still be synchronized via the below work-around:

  1. Go to the JIRA -> Project -> Administration -> Issue Types page to determine the workflow for the issue type to synchronize.
    For example: Project Simple Issue Tracking, Issue Type Bug:

  2. Ask a JIRA administrator to export the workflow as an XML file.
    For example: Workflow SIT: Simple Issue Tracking Workflow:

  3. Choose Sync from file and select the appropriate JIRA workflow XML file.


Only choose not to synchronize the workflow (now/again), if

  • the codebeamer State Transitions are already compatible with the JIRA Workflow, or
  • the codebeamer State Transitions are intended to be edited manually.

Synchronizing Workflows (by replacing the codebeamer Workflow with the JIRA Workflow) can have side effects:

  • If the codebeamer tracker already contains items, and those items are in a Statusthat is not a mapped JIRA target status,
    • the existing State Transitions from/to this Status are removed,
    • the Status itself is marked as obsolete.

Synchronize with JIRA

Having completed the JIRA Synchronization configuration,

  • Synchronization
  • Import
  • Export

can be performed depending on the configured synchronization Direction:





The first/initial synchronization is always a full import/export.

Even if automatic synchronization had been configured in regular time intervals, this scheduled synchronization only starts after the first/initial manual synchronization.


Since the initial import/export potentially imports/exports lots (hundreds/thousands) of tracker items, the import/export statistics only show numbers, but not the actual item information.





All subsequent synchronizations are incremental imports/exports:





Synchronizing again immediately, or shortly after a previous synchronization typically shows that the synchronization has finished successfully, however, there was no new data to synchronize.


After making relevant changes either in JIRA or in codebeamer,

for instance,

  • changing the Status of an item
  • changing some attributes, for example Story Points
  • adding a new Comment and Attachment,

a new synchronization run should reflect these changes:





For incremental Import/Export runs, detailed information about imported, updated, deleted or failed data is available, for example, 1 item updated:





The configured number of the last X synchronizations can also be viewed at any time later by clicking on the the History... link on the JIRA Synchronization dialog:





Administrators can also look at the synchronization settings that were in effect for each of the synchronizations.

The synchronization history does not store synchronization runs where there was no data to synchronize.


Subsequent changes of either the codebeamer Tracker configuration or the remote JIRA configuration (e.g., new fields, new choice options, workflow changes, etc.) have no effect unless the Synchronization Settings are manually edited and updated.



Since codebeamer 10.0, a Tracker Synchronization Listener can be implemented and deployed to be notified whenever a Tracker is synchronized with JIRA.



Known limitations

  • Individual trackers in projects that have been imported from Atlassian JIRA© via Importing Projects from Atlassian Jira cannot be synchronized. Also not trackers of type:
    • Release
    • Component
    • Team
    • Pull Request
    • Test Run
    • Time Recording
  • Both synchronization end-points: the codebeamer Tracker and the JIRA© Project and Issue Type must already exist.
  • codebeamer can only adjust its own configuration to JIRA's configuration, but not vice versa.
  • To configure a JIRA synchronization, the specified JIRA user must be an Administrator of the selected JIRA project, otherwise, access to JIRA issue type meta data is denied.
  • To synchronize JIRA workflows automatically, the specified JIRA user must have JIRA (System) Administration permission.
    • A work-around is available for manual workflow synchronization without (direct) JIRA administration access.
  • Sub-Tasks of the selected JIRA issues are not imported/synchronized to codebeamer because their issue type is different.
  • In codebeamer 9.0 and older, only the top-level items in the codebeamer Tracker are exported/synchronized to JIRA , descendants are not.
  • Since codebeamer 9.1 and newer, all items in the codebeamer Tracker are exported/synchronized with JIRA as a flat issue list (no parent/child relationship in JIRA).
  • Only JIRA Core User, Group, Version and Component references/pickers are supported. References defined by JIRA Plugins and Extensions are not supported.
  • Usersimported from JIRA (where no user with the same name already existed in codebeamer) are initially disabled, to avoid exhausting the license pool, and not members of the project.
    • Disabled users cannot be selected as new member field values (for example, Assigned to). Assigning non-project members are not possible either.
    • To assign codebeamer items to imported JIRA users:
    • activate the user,
    • assign the user to a project role.
  • Only JIRA Core/Custom Fields can be synchronized with the following exceptions:
    • Labels
    • Votes
    • Watchers.
  • Since codebeamer 9.3 and newer, JIRA Agile fields: Sprint and Epic Link, and the JIRA Portfolio's Teamfield can be synchronized.
    • Due to a known bug in the JIRA Portfolio's REST API, exporting Team changes from codebeamer to JIRA fails with an Internal Server Error in JIRA.
      As long as this JIRA bug is not fixed, the Team field should only be imported but not exported/synchronized.
  • Fields defined by other JIRA Plugins and Extensions cannot be synchronized unless support is provided for special JIRA custom fields (only since codebeamer 2021)
  • Only the Fields on the Create Issue screen (for the selected JIRA Project and Issue Type) are available for synchronization.
  • Exporting new codebeamer tracker items to JIRA fails if the JIRA Create Issuescreen contains mandatory (custom) fields
    • that are not supported by codebeamer and
    • that do not have a default value.
  • There is a limited conversion between JIRA Wiki Text and codeBeamer Wiki Markup:
    • Headings
    • Text Effects: Bold, Italic, Strike-through, Underlined, Superscript, Subscript, Monospaced, Quotes, Text Color
    • Preformatted Text
    • Text Breaks
    • Links
    • Lists
    • Images
    • Tables: Only the basic simple table markup is supported by both systems.
      • Cells that contain newlines/span multiple lines are not rendered properly in codebeamer.
      • Tables defined via the codebeamer Table Plugin are not rendered at all or only partially in JIRA.
    • Any other Advanced JIRA and/or codebeamer markup are exchanged as is, and are either not be rendered at all, or are not rendered as expected by the other system.
      • For example: JIRA Attachments, Panels, Code sections, Smileys, etc.
      • For example. codebeamer Wiki Plugins, Interwiki Links, etc.
  • Only Comments visibility restrictions based on a single role can be synchronized, and only if Roles are synchronized.
  • codebeamer can only read/import the JIRA Change Log. Writing/exporting its own change history to JIRA is not possible.
    • Only Change Log entries related to mapped Fields are imported.
  • Exporting issues from codebeamer to JIRA is more than 10 times slower than Importing issues from JIRA into codebeamer, because
    • each issue and each comment, attachment and worklog entry to export requires a separated JIRA REST API request.
  • All (exported) issues, issue changes, attachments, comments and worklog entries are associated with the JIRA user, used for JIRA synchronization,
    • not with that user, that originally created the issue (change), comment or worklog entry in codebeamer.
  • Importing/Updating JIRA issues does not trigger any notifications or workflow actions on the codebeamer tracker.
  • Removing/Deleting issues in codebeamer or in JIRA is synchronized,
    • because codebeamer tracker items can only be removed (and probably restored),
    • but JIRA deletes issues immediately without the possibility to restore.


Frequently asked questions

Question

Is a filtered import possible with the current interface?

Answer

No. All issues of the selected type in the JIRA project will be imported and all (top-level) items in the codebeamer tracker will be exported. There are currently no plans to support such a filtered synchronization.



Question

Is importing one JIRA element into several trackers (in different codebeamer projects) allowed?

Answer

No. You can associate one JIRA project/issuetype with exactly one codebeamer tracker at any time.

Once associated, you can only re-assign a JIRA project/issuetype to a different tracker after removing the JIRA synchronization from the previously assigned project/tracker.

The reason for this are issue links:

  • If you import a JIRA issue that has links to JIRA issues of other types or in other projects, then codebeamer will check if the referenced issues have already been imported, and if yes,
    • will create appropriate tracker item associations between the imported items and the previously imported referenced items.
  • If we would allow to import the same JIRA issues multiple times into different trackers, then the mapping of referenced JIRA issues to imported codebeamer tracker item would become ambiguous!



Question

What happens if a codebeamer tracker item is deleted which is synchronized with a JIRA issue?

Answer

The tracker item still exists, only in trash. The JIRA synchronization will continue importing relevant modifications of the associated JIRA issue to the tracker item in trash. So when the tracker item gets eventually restored later, it will still be in sync with the JIRA issue.



Question

What happens if an issue is deleted in JIRA which is synchronized with codebeamer?

Answer

JIRA issues are deleted physically, so there is no trace left of them. Upon a subsequent import, codebeamer will not get any hint about the issue deletion so the codebeamer tracker item will persist.

Only when codebeamer tries to synchronize changes made in codebeamer back to JIRA, it will detect, that the target JIRA issue does not exist anymore. Only in this case:

  • The JIRA synchronization status of the tracker item will be cleared (including the JIRA Key).
  • To prevent future synchronization attempts for this item that are doomed to fail: The JIRA ID of the item will be set to 0 (zero).



Question

What happens if a JIRA project is deleted where issue types are synchronized with codebeamer?

Answer

The next JIRA synchronization of all codebeamer trackers associated with issue types in the deleted JIRA project will fail. If this was an automatic/periodic synchronization, any further synchronizations for this tracker will be cancelled.

A tracker administrator has to decide how to continue but basically the only thing (s)he can do is to remove the synchronization with the deleted JIRA project.



miniOrange plugin

codebeamer does not implement the miniOrange authentication flow for SSO. Make sure that the API of the used JIRA server is available without SSO authentication.


If not, the following error message is displayed:

Could not extract response:no suitable HttpMessageConverter found for response type