Synchronizing Trackers with Atlassian JIRA©

In codebeamer 9.0 and newer, there is a new Synchronization (Import and/or Export) between Intland codebeamer and Atlassian JIRA© on tracker level.

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

Synchronizing Trackers with Atlassian JIRA© Cloud is only supported in CB-9.4 and newer!

If you had used CB-9.3 or older, to synchronize trackers with JIRA© Cloud (which is not working anymore, due to changes in the JIRA© Cloud REST API),
and you want to continue that synchronization with CB-9.4 and newer,
then you have to carefully follow the Migration Steps in Synchronizing Trackers with Atlassian JIRA© Cloud!

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.

Each codebeamer Tracker can be associated with at most one JIRA Project and Issue Type at a time!

Such an association can be configured at any time, even for trackers which are not empty.

There is no restriction, what type of JIRA issue type can be associated with a tracker of a specific type. But this seems to be the obvious mapping:

You cannot synchronize individual trackers in projects which have been imported from Atlassian JIRA© via Bi-directional synchronization between Atlassian JIRA© and codeBeamer. And also not trackers of type:

• Release
• Component
• Pull Request
• Test Run
• Time Recording

If the current tracker is not associated with a JIRA Project and Issue Type yet, and you have Tracker Admin permissions, you can choose to configure it now:

JIRA Synchronization Settings

First you have to enter the Web-Address (hostname, ip-address and port) of the remote Atlassian JIRA© Server and a Username and Password to login:





If the Server is a JIRA© Cloud instance (https://instance.atlassian.net), you must not enter the username and password of the JIRA© Cloud user. Instead, use:

• Username : the Atlassian account email address
• Password : the API token.

Then you need to Select... the JIRA© Project and Issue Type to associate with the current tracker:

Please note:

• The specified JIRA user must 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 will not be imported/synchronized to codebeamer.
  • In CB-9.0 and older: only the top-level items in the codebeamer Tracker will be exported/synchronized to JIRA but no descendants.
  • In CB-9.1 and newer: all items in the codebeamer Tracker will be exported/synchronized to JIRA as a flat issue list (no parent/child relationship in JIRA).

JIRA Synchronization Direction

The default synchronization Direction is Import Only but you can change that, e.g. to Synchronize bi-directionally:





By default, the synchronization (in the specified direction) is Enabled but you can disable (and re-enable later) at any time, by (un-)checking the appropriate checkbox.

JIRA References Synchronization

Before you start with mapping fields of the JIRA Create/Edit issue screens with codebeamer Tracker fields, you should decide, how to handle specific 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 (only CB-9.3 and newer) are imported as static choice field options.
• Epic links (only CB-9.3 and newer) are imported as JIRA Epic keys.

In order to map the JIRA issue Reporter/Assignees to codebeamer's item Owner/Assigned to attributes, you have to 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) already exists, will be created as codebeamer users
• Only these user attributes will be imported:
  • user name,
  • first/given name,
  • last/family name,
  • email address,
  • (avatar/picture)
• All imported users will be initially disabled,
  • because 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.
• You cannot assign codebeamer tracker items to disabled users or to non-project members.
  • In order to be able to assign codebeamer items to imported JIRA users,
    • you must first activate the imported users
    • and assign the users a role in the codebeamer project.
• Because this synchronization is on tracker level, the imported users will not be member of the codebeamer Project!
• Updating a user in JIRA will only update the appropriate codebeamer user if that user was originally imported from JIRA.
• Deleting a user in JIRA which was previously imported to codebeamer, will not delete that user in codebeamer, because deleting users in codebeamer is generally not possible.
• Modifying a user in codebeamer which was imported from JIRA, will not synchronize those changes back to JIRA.

Please note: The codebeamer item Submitted at and Last Modified at dates also depend on the Users handling. You should only import Submitted at, if you are also importing Submitted by!


In order to map the JIRA issue Affects Version/s/Fix Version/s to codebeamer's item Detected in/Release attributes, you have to enable Versions import:

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

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

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

In order to map the JIRA issue Team field to codebeamer's standard item Team field, you have to enable Teams import (CB-9.3 and newer):

• 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, whose name is Team or Teams, and whose choice options are the defined Teams.
• JIRA Teams will be imported as config items into the Teams tracker in the current project.
• Modifications of JIRA Teams (Create, Update or Delete) will be synchronized to codebeamer.
• Modifications of imported Teams in codebeamer or adding new Teams in codebeamer will not be synchronized back to JIRA but remain private to codebeamer.

In order to refer to JIRA Epics as codebeamer work items (CB-9.3 and newer), you have to enable Epics linking:

• You can only enable Epics linking, if the issue type Epic in the JIRA project is synchronized with an appropriate tracker of type Epic in the codebeamer project.
• There is no pre-defined codebeamer Epic reference field, so you will have to define a new/custom target field for the JIRA Epic Link field.

JIRA Fields Synchronization

Next you have to map JIRA issue Fields to codebeamer Tracker fields.

The JIRA issue

• Id,
• Key,
• Summary and
• Description

are always synchronized implicitly according to the synchronization Direction.

The JIRA issue Attachments (see below) will be synchronized by default but you can change this, if necessary.

All other Fields (system or user defined) must be mapped to Tracker Fields manually.

Only the fields on the Create Issue screen for the selected JIRA Project and Issue Type will be available for synchronization.

So if you are missing a field here, then check the appropriate Create Issue screen configuration in JIRA!

The values of the JIRA issue

• Creator,
• Created and
• Updated

fields can only be imported into codebeamer.

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

The same restrictions also apply to the JIRA Change Log: codebeamer can read/import the JIRA change log but not write/export its own change history to JIRA!

For each field, you can configure, whether to:

• Ignore (not synchronize) this field
• Only Import values of this field (JIRA codebeamer)
• Only Export values of this field (JIRA codebeamer)
• Synchronize field values bi-directionally (JIRA codebeamer)

E.g.

In addition:

• Values of JIRA fields which are not editable/writable (by the specified user) can only be imported but not exported.
• Values of codebeamer fields which are not editable, e.g. fields with computed values can only be exported by not imported.

Fields which are mandatory/required in JIRA are marked with a red star. If you

• do not map mandatory fields to codebeamer tracker fields, or
• do not export/synchronize the codebeamer field value (back) to JIRA,

then exporting new codebeamer tracker items to JIRA (which means "Create a new JIRA issue") will most probably fail, unless the JIRA field has a default value!

Please also note that the field value synchronization mode is not restricted by the currently selected synchronization Direction:

• You can configure to export or bi-directionally synchronize field values, even if the current Direction is Import Only, or vice versa.
• This way, you do not have to adjust all field synchronization modes every time you change the synchronization Direction.

But upon each synchronization run, only those fields will be synchronized, where the field synchronization mode points into the actual synchronization direction, where a Synchronization is an Import followed by an Export.

For JIRA picker fields, choice values also have to be mapped to codebeamer ALM's choice options (missing choice options can be created, if necessary, via -- New...).

e.g. JIRA Status codebeamer Status:

Be very careful, when creating -- New ... codebeamer Status options:

• Tracker Fields can have specific Permissions and Allowed Values per Status
  • Such fields would not have allowed values and permissions for the newly added Status, so these fields would not be visible/editable for imported items in this Status.
• If the Tracker Workflowis active, then
  • No State Transitions will lead into or out of the newly added Status
  • Imported items in this Status will not be able to proceed in the workflow, unless the newly added Status is connected via newly defined State Transitions.

The JIRA connector will 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.

And even then, the workflows will only be synchronized (by replacing the codebeamer workflow with the JIRA workflow, see below), if

• The user has JIRA System Administator permission, or
• The user synchronizes the workflows manually.

If there are multiple/lots of JIRA choice options which need to be mapped to new target choice options, then you can automatically create new target options for all of them, by clicking on the arrow down icon behind 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, via -- New....

E.g Create a new field for Component/s:

You can 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 CB-9.2 and older, only JIRA Core Fields can be synchronized but not fields defined by JIRA plugins and extensions, e.g. Epic links from JIRA Agile:



CB-9.3 and newer can also synchronize JIRA Agile Fields, e.g. Sprint and Epic Link:



There is no pre-defined codebeamer Epic reference field, so you will have to define a new/custom target field for the JIRA Epic Link field.
If Epics linking is enabled (see above), the target tracker field will be a reference field to the imported Epic work item, otherwise, it will be 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 assigns (work) items to releases and sprints only via the predefined (target) versions reference field (the field label can be different, e.g. "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.

So, in order for the codebeamer Release and Sprint planning, to work also with imported JIRA issues:

• both, JIRA Versions and JIRA Sprints,
  • will be imported into the same codebeamer Releases tracker,
    • since there is no relation between Sprints and Versions in JIRA, imported Sprints will be top-level items in CB.
  • will be associated with work items via the same (target) versions field.
    • There will be 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, you should also choose, whether to also ignore, import, export or synchronize:




The Roles mapping is primarily for synchronizing

• Fields of type Role(s)
• Comments visibility 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), e.g. "Submitter", "Assigned To", "Owner".
  • The only common restriction that can be synchronized is therefore a single role.

Please note that creating a -- New... target role will only create an appropriate role stereotype/value but not an actual Role in the target codebeamer project!

In JIRA, there is a limit for the maximum size of issue attachments!
If you configure to export/synchronize Attachments, then please ask your JIRA adminstrator to check/adjust the issue attachment size limit.

Please note that you can only synchronize Comments, Worklog and Change Log, if you are also synchronizing Users!

The Worklog will be imported as items of the Timekeeping Tracker in the codebeamer Project and will be shown as Time Recordings for Subject under the References of the imported issue.

If the JIRA Change Log should be imported as codebeamer issue History, then only Change Log entries about mapped Fields are imported, other entries are simple ignored, such as:

• Project
• Key
• Workflow
• Labels
• etc.

There are also JIRA Change Log entries about 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 but not write/export its own change history to JIRA!

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

• The export will be executed as the JIRA user specified in the JIRA synchronization settings.
• All (exported) issues, issue changes, attachments, comments and worklog entries will be 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

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

For each link type, you can configure, whether to:

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

CB-9.3 and older, also errorneously allowed to configure, whether to

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

But 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, e.g. every 4h:





The smallest allowed synchronization Interval is 10 min.

If the synchronization runs very frequently, you should limit the size of the synchronization History/Log, e.g. to only keep the last 100 synchronizations.

Please note: The first/initial synchronization has always to be started manually, because there may still be some additional/manual Tracker Customization 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

In order to re-use the JIRA Synchronization Settings of one tracker (as a template) for other tracker synchronizations as well, you can

• Save a configuration as a configuration file, and then later
• Load this configuration file when configuring another tracker synchronization.

Please note that loading a configuration from file will overwrite the current settings. So you should do this right at the beginning!

Removing JIRA Synchronization

In CB-9.0 and older, you cannot remove a JIRA synchronization from a tracker, once it was configured.

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

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

Since CB-9.1, you can now remove a JIRA synchronization from a tracker, via Remove... in the JIRA synchronization settings.

This is also an irreversibe process that will delete

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

But in contrast to deleting the tracker: the tracker itself, the tracker configuration and also the tracker items will remain.

But beware: Tracker items that were previously synchronized with JIRA, are now no longer recognized as such!

• If you later import other JIRA issues (into a different tracker) that have links to JIRA issues, that were previously represented by items in this tracker,
  • then the newly imported items will not refer to any items in this tracker.
• Should you later setup JIRA synchronization for the same tracker again, perhaps even associated with the same JIRA project and issuetype than before:
  • Importing will not update any existing tracker items but will create new items for all JIRA issues instead.
  • Exporting will export all existing items as new JIRA issues and not update any existing JIRA issues.

In CB-10.0 and newer, you can implement and deploy a Tracker Synchronization Listener, in order to be notified, whenever a Tracker is attached/detached with JIRA or the JIRA Synchronization Configuration changes.

JIRA Workflow synchronization

If you have mapped the JIRA Issue Status field to the codebeamer Tracker Item Status field (for export or bi-directionally, then

• The JIRA Issue Resolution field must also be mapped to an appropriate codebeamer Tracker Item field and that field value must also be synchronized to JIRA.
• The codebeamer State Transitions must be synchronized with the JIRA issue workflow, otherwise, exporting codebeamer status changes to JIRA may not be possible.

• Do not map Status at all, or
• Import the JIRA Statusto a new custom tracker field, e.g. "JIRA Status"
  • Only if you need synchronization between codebeamer Status and JIRA status (at specific synchronization points), then
    • Configure actions in the appropriate codebeamer State Transitions or workflow Event Handlers that change the "JIRA Status" accordingly

If the JIRA user you have configured for the JIRA synchronization, has "Administer projects" permissions on the JIRA project, then codebeamer can do the necessary JIRA issue workflow synchronization automatically.

Otherwise, you will be asked to do the workflow synchronization manually:

If you choose to

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

then you are asked, to enter the username and password of a JIRA user with "Administer projects" permissions on the JIRA project.

If you do not have direct project administrator access, then you can still synchronize the workflow via this work-around:

• Look at the JIRA -> Project -> Administration -> Issue Types page to determine the worflow for the issue type to synchronize: e.g. Project Simple Issue Tracking, Issue Type Bug:
  
  
  
• Ask a JIRA administrator to export this workflow as an XML file: e.g. Workflow SIT: Simple Issue Tracking Workflow:
  
  
  
• Choose Sync from file and select the appropriate JIRA workflow XML file.

You should only choose to not synchronization the workflow (now/again), if

• The codebeamer State Transitions are already compatible with the JIRA Workflow, or
• You are going to edit the codebeamer State Transitions manually.

Please be aware that 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 Status that is not a mapped JIRA target status
  • The existing State Transitions from/to this Status will be removed
  • The Status itself will be marked as obsolete

Synchronize with JIRA

After having completed the JIRA Synchronization configuration, or any time via Tracker -> Synchronize with JIRA, you can now start a

• Synchronization,
• Import or
• Export

depending on the configured synchronization Direction:

The first/initial synchronization will always be a full import/export.

Even if you have configured automatic synchronization in regular time intervals, this scheduled synchronization will only start after the first/initial manual synchronization!

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

All subsequent synchronizations will then be incremental imports/exports:

Synchronizing again immediately or shortly after a previous synchronization will typically show

• The synchronization has finished successfully but there was no new data to synchronize.

But if you make some relevant changes either in JIRA or in codebeamer, e.g

• Change the Status of an item
• Change some attributes, e.g. Story Points
• Add a new Comment and Attachment

then a new synchronization run should reflect these changes:

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

The configured number of the last X synchronizations can also be viewed at any time later, via the History... link in the JIRA Synchronization dialog:





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

Note: The synchronization history does not remember synchronization runs, where there was nothing to synchronize.

In CB-10.0 and newer, you can implement and deploy a Tracker Synchronization Listener, in order to be notified, whenever a Tracker is synchronized with JIRA.

Known limitations

• You cannot synchronize individual trackers in projects that have been imported from Atlassian JIRA© via Bi-directional synchronization between Atlassian JIRA© and codeBeamer. And also nottrackers 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.
  • But there is a work-around for manual workflow synchronization without (direct) JIRA adminstration access
• Sub-Tasks of the selected JIRA issues will not be imported/synchronized to codebeamer, because their issue type is different.
• In CB-9.0 and older: only the top-level items in the codebeamer Tracker will be exported/synchronized to JIRA but no descendants.
• In CB-9.1 and newer: all items in the codebeamer Tracker will be exported/synchronized to JIRA as a flat issue list (no parent/child relationship in JIRA).
• Only JIRA Core User, Group, Version and Component references/pickers are supported but no references defined by JIRA Plugins and Extensions
• Usersimported from JIRA (where no user with the same name already existed in codeBamer) are initially disabled, to not exhaust the license pool, and not members of the project.
  • You cannot choose disabled users as new member field values, e.g. Assigned to, nor can you assign non-project members.
  • In order to be able to assign codebeamer items to imported JIRA users:
  • You must first activate the user, and
  • You must assign the user to a project role.
• Only JIRA Core/Custom Fields can be synchronized, with the following exceptions:
  • Labels
  • Votes
  • Watchers
• Only CB-9.3 and newer can also synchronize JIRA Agile fields: Sprint and Epic Link, and the JIRA Portfolio's Teamfield
  • Due to a known bug in the JIRA Portfolio's REST API, exporting Team changes from codebeamer to JIRA will fail 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 you Add support for special JIRA custom fields (only CB-2021 and newer)
• Only the Fields on the Create Issue screen for the selected JIRA Project and Issue Type will be available for synchronization.
• Exporting new codebeamer tracker items to JIRA will fail, 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 will not render at all or only partially in JIRA
  • Any other Advanced JIRA and/or codebeamer markup will be exchanged "as is" and will most likely not be rendered at all or not be rendered as expected by the other system
    • e.g. JIRA Attachments, Panels, Code sections, Smileys, etc.
    • e.g. 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 but not write/export its own change history to JIRA!
  • Only Change Log entries about 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 will be 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 will not trigger any notifications or workflow actions on the codebeamer tracker.
• Removing/Deleting issues in codebeamer or in JIRA will not be synchronized,
  • because codebeamer tracker items can only be removed (and probably restored),
  • but JIRA deletes issues immediately without possibility to restore.

Frequently asked questions

Is a filtered import possible with the current interface ?

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.

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

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!

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

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.

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

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 any more. 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).

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

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

Please note that codebeamer does not implement the miniOrange authentication flow for SSO, you need to make sure that API of you jira server is available without SSO authentication.

If not, you will get the following error message

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