Sync Other System Fields

Configuration

In order to sync other system fields, the following configuration must be set to true.

YAML

serverfrom:
  # add setting to the serverFrom
  syncOtherSystemFields: true

After setting the syncOtherSystemFields to true, the next steps is to define the which fields to sync.

The currently supported fields are the following:

Labels
Fix Versions
Affects Versions
Components

Add the following configuration on the serverfrom setting to sync the fields

YAML

serverfrom:
  # add setting to the serverFrom
  syncOtherSystemFields: true
  syncOtherSystemFieldsList:
    labels: true
    fixVersion: true
    affectsVersion: true

By adding the complete configuration above, this will sync all the labels, fix versions and affects version from the source system to the target system.

Additional Configuration

Override Target System Values

Currently affected fields:

Labels
Fix Versions
Affects Versions

Configuration

YAML

serverfrom:
  # add setting to the serverFrom
  syncOtherSystemFields: true
  syncOtherSystemFieldsList:
    labels: true
    labelsOptions:
      overrideTargetLabels: true # Add this option to override target system labels
    fixVersion: true
    fixVersionOptions:
      overrideTargetVersions: true # Add this option to override target system fix versions
    affectsVersion: true
    affectsVersionOptions:
      overrideTargetVersions: true # Add this option to override target system affects versions

The configuration above will make sure that the values from the Source system will always be followed. If there is a mismatch between the source and the target systems, the fields will be synced to be identical to the source system.

Value Mapping

Currently affected fields:

Fix Versions
Affects Versions

Configuration for Fix Versions

YAML

serverfrom:
  # add setting to the serverFrom
  syncOtherSystemFields: true # syncOtherSystemFields must be set to true
  syncOtherSystemFieldsList:
    fixVersion: true
    fixVersionOptions:
      overrideTargetVersions: false
      useMapping: true # Default false. Set to true to use mapping.
      mapping:
        "Version 1.0": "Version A"
        "Version 2.0": "Version B"

Configuration for Affects Versions

YAML

serverfrom:
  # add setting to the serverFrom
  syncOtherSystemFields: true # syncOtherSystemFields must be set to true
  syncOtherSystemFieldsList:
    affectsVersion: true
    affectsVersionOptions:
      overrideTargetVersions: true
      useMapping: true # Default false. Set to true to use mapping.
      mapping:
        "Version 1.0": "Version A"
        "Version 2.0": "Version B"

useMapping is set to true.
- if useMappingis set to false; then the fix versions and/or affects version will sync based on the versions set on the Source system ticket instead of the mapping. It will create the versions on the Target systems if it’s not yet existing.
mapping is set with the keys are the Source system versions and the values are the Target system versions.
Keys and values of mapping must be wrapped in double quotes.
The versions configured in mapping must be existing in both the Source and Target systems.

Notes on the behavior of the Other System Field Sync

Adding or removing values from the source system

Currently Affected fields:

Labels
Fix Versions
Affects Versions
Components

If the value of the fields exist on the Source system and does not yet exist on the Target system. Advanced Issue Sync will proceed to create the same value on the target system.

How the sync handles the adding or removing of values

The default behavior of the sync is that all edits done on these fields on the source system will also be done on the target system. An example is when a label is added on the source system, it will also be added to the target system. It will also be the same for labels that are removed.
When a value for the field is added on the target system, unless the override setting is configured, it will remain there but any changes done to the source system will reflect on the target system.
- Example Use Case:
  - Create a ticket on the source system (SRC-1) with the following labels: data-center, advanced-issue-sync.
  - Run the Advanced Issue Sync.
  - A ticket will be created on the target system (TGT-1) with the following labels: data-center, advanced-issue-sync.
  - From the target system ticket (TGT-1) a new label is added: dependency-ticket
  - The target system ticket (TGT-1) will now have three labels: data-center, advanced-issue-sync, and dependency-ticket.
  - From the source ticket (SRC-1) a label was removed: data-center.
  - Run the Advanced Issue Sync.
  - The target system ticket (TGT-1) list of labels will have data-center removed and the only labels left would be: advanced-issue-sync and dependency-ticket.
If the usemapping configuration is set to true for fixVersionOptions and/or affectsVersionOptions. The adding and removing of values will be according to the mapping that is set.
- Sample Use Case:
  - Version 1.0 is mapped to Version A
  - If Version 1.0 is existing on the source ticket; the target ticket will be updated to have Version A.
  - If Version 1.0 is removed from the source ticket; the target ticket will be updated and have Version A removed.

Additional Notes on Components with Default Assignee

If a component on the target project has a default assignee configured (e.g., Project Lead), newly created issues with that component will initially receive that default assignee. However, if user mapping is configured and the source issue has an assignee with a valid mapping, the mapped assignee will take precedence over the component's default assignee.

Configuration using Sync Settings

Currently Affected fields:

Fix Version

Basic Configuration

YAML

serverfrom:
  ...
serverto:
  ...
pushJQL:
  ...
# add field sync using syncSettings
syncSettings:
  fieldSync:
    systemFields:

Enable Sync for FixVersions

YAML

syncSettings:
  fieldSync:
    systemFields:
      fixVersion:
        enabled: true

Add Fix Version Sync Direction (required)

YAML

syncSettings:
  fieldSync:
    systemFields:
      fixVersion:
        enabled: true
        # direction - one-way, two-way, or back-sync workflow status sync.
        # one-way - source to target
        # two-way - source to target and target to source
        # back-sync - target to source
        direction: two-way

Add conflict resolution for Fix Version sync

YAML

syncSettings:
  fieldSync:
    systemFields:
      fixVersion:
        enabled: true
        direction: two-way
        # conflictResolution - setting for two way status sync to determine how to handle conflict.
        # conflict means both source and target was changed before sync.
        # choose only one. serverPriority or latestChangePriority
        conflictResolution:
          # serverPriority - this setting will let jira sync decide which server takes priority if there's a conflict
          serverPriority:
            enabled: true
            # server choices (source or target)
            server: source
          # latestChangePriority - this setting will use the issue with the most latest status change if there's a conflict
          latestChangePriority:
            enabled: false

Notes on Conflict Resolution behavior for Fix Versions

The versions that will be retained will be the current state of priority based on configuration..
For example, the following versions are set to both the source ticket and the target ticket and the conflict resolution is set to latestChangePriority.
- Version A
- Version B
- Version C
- Version D
Both are updated chronologically with the following changes:
- Source issue removes Version B, Version C, and Version D
- Target issue removes Version A
Since the Target issue is the newer change; the versions that will be set to Source issue will be Versions B, Version C, and Version D.
The Version A will be removed from the Source ticket since that is what was removed from the Target ticket which is the priority based on the conflict resolution.