Assistance for Sync Monitoring, Comment Handling, Remote Key, and Connection JQL

General Questions
,
1

1. under_sync_by_connection() cannot find our connection

We are trying to retrieve issues belonging to a specific Exalate connection using:

    issue in under_sync_by_connection(
        "NeoTest_to_CHAMP Jira Test - NHC and NHS Project"
    )

However, Jira returns:

    No connection of name
    'NeoTest_to_CHAMP Jira Test - NHC and NHS Project'
    could be found

We confirmed under **Exalate → Connections → Info** that this is the exact Connection Name.

As a comparison, another connection works correctly:

    issue in under_sync_by_connection("ChampNEO_to_ChampNEOSWP")

Could you please confirm:
  • Whether spaces or special characters in the connection name can affect under_sync_by_connection()
  • Whether this is a known issue or limitation in Exalate
  • Whether there is another supported way to reference the affected connection
  • Whether the existing connection can safely be renamed, for example to:
            NeoTest_to_CHAMP_JiraTest_NHC_NHS

2. Displaying actual Exalate Sync Status in a Jira Dashboard

We would like to create a Jira dashboard for monitoring the CHAMP ↔ Swissport synchronization.

Ideally, we would like each Jira issue to display its actual Exalate synchronization state, such as:

    SYNCHRONIZED
    WAITING FOR REMOTE
    IN PROGRESS
    ERROR

We can currently use:

    issue in under_sync()

and we are also evaluating `sync_stuck()`.

However, these do not appear to expose the exact status displayed in the Exalate **Sync Status** panel on each Jira issue.

Could you please confirm whether there is a supported way to expose the actual Exalate synchronization status as:

  • a Jira custom field,

  • a JQL function,

  • a dashboard/filter column,

  • an Exalate API value,

  • or another supported monitoring mechanism?

    Our goal is to have a dashboard similar to:

    CHAMP Key    Swissport Key    Exalate Status
    NHC-xxxxx    PM1-250          SYNCHRONIZED
    NHS-xxxxx    PM1-251          WAITING FOR REMOTE
    NHC-xxxxx    PM1-252          ERROR

3. Internal comments by default / explicit external comments

Our requirement is that Jira comments should remain **internal to CHAMP by default** and should only be synchronized to Swissport when a CHAMP user explicitly     marks the comment as external.

We are considering using a keyword/prefix such as:

    [SWP]

For example:

    Internal investigation is still ongoing.

should remain only in CHAMP Jira.

While:

    [SWP] We have reproduced the issue and are currently testing a fix.

should be synchronized to Swissport.

We are currently considering the following outgoing sync rule:

    replica.comments = issue.comments.findAll { comment ->
        comment.body?.trim()?.startsWith("[SWP]") &&
        !comment.groupLevel &&
        !comment.roleLevel
    }

The intention is:

    No [SWP] prefix + Viewable by All Users
    → Visible to eligible users in CHAMP Jira only and NOT synchronized to Swissport

    [SWP] + Viewable by All Users
    → Synchronize to Swissport

    [SWP] + restricted to a Jira Group/Project Role
    → Do not synchronize to Swissport

Could you please confirm whether this is a **supported and recommended Exalate approach** for Jira Data Center?

We would also appreciate your recommendation if Exalate provides a better supported mechanism for implementing:

**Internal by default → explicitly marked external comment → synchronize to remote Jira.**

If the prefix approach is recommended, is it also supported to remove `[SWP]` from the comment before sending it to the remote side, so Swissport only receives the actual comment text?

4. Jira custom field for the equivalent Swissport issue key

We would also like the corresponding Swissport Jira issue key to be visible directly in CHAMP Jira Issue Search and Jira Dashboard.

For example:

    CHAMP issue: NHC-xxxxx
    Swissport issue: PM1-250

We are considering creating a Jira text custom field such as:

    Exalate Remote Issue Key

and populating it through the Exalate incoming sync rule using the remote issue key, for example:

    issue.customFields."Exalate Remote Issue Key".value = replica.key

Could you please confirm whether this is the **recommended and supported method** for storing and displaying the remote Jira issue key?

Since CHAMP may initiate the synchronization and the Swissport issue key does not exist until the remote issue is created, please also advise whether we should use `syncBackAfterProcessing()` or another supported mechanism to return the newly created Swissport key to CHAMP.

Our objective is ultimately to have a Jira dashboard where administrators can easily see:

    CHAMP Key | Swissport Key | Jira Status | Exalate Sync Status

Please let me know if you need anything else from my side.
Thank you.

2

Great set of questions! Let’s break down each point and clarify the best practices and supported approaches for your use cases.

  1. under_sync_by_connection() and Connection Names
  • Spaces and special characters in connection names can affect the under_sync_by_connection() JQL function. The function expects the exact connection name as registered in Exalate, but certain characters (like spaces, dashes, or special symbols) may cause issues with recognition in JQL.
  • This is a known limitation. If the function cannot find your connection, try renaming it to use only alphanumeric characters and underscores (e.g., NeoTest_to_CHAMP_JiraTest_NHC_NHS). Renaming a connection is supported and safe; it won’t break existing syncs, but you should update any references in scripts or dashboards accordingly.
  • There is no alternative way to reference a connection in under_sync_by_connection()—it relies on the connection name.
  • More details: JQL functions for Exalate.
  1. Displaying Actual Exalate Sync Status in Jira Dashboards
  • The under_sync() and sync_stuck() JQL functions only indicate if an issue is under sync or stuck, not the granular sync status (like SYNCHRONIZED, WAITING FOR REMOTE, etc.) shown in the Exalate panel.
  • There is currently no built-in JQL function or custom field that exposes the detailed Exalate sync status directly in Jira dashboards or filters.
  • For advanced monitoring, you can use the Exalate REST API to fetch sync statuses and build a custom dashboard (e.g., with Jira gadgets or an external reporting tool).
  • Reference: Monitoring synchronization status and Exalate REST API.
  1. Internal Comments by Default, Explicit External Comments
  • Your approach using a prefix (like [SWP]) in the outgoing sync script is supported and commonly used. The script you provided is correct for filtering comments to sync only those explicitly marked for external sharing.
  • To remove the [SWP] prefix before sending the comment to Swissport, you can modify the outgoing sync rule as follows:
    replica.comments = issue.comments.findAll { comment ->
    comment.body?.trim()?.startsWith("[SWP]") && !comment.groupLevel && !comment.roleLevel
}.collect { comment ->
    def newComment = comment.clone()
    newComment.body = comment.body.replaceFirst(/\[SWP\]\s*/, "")
    return newComment
}
  • This ensures only comments intended for Swissport are sent, and the prefix is stripped out.
  • More info: Syncing comments with Exalate.
  1. Jira Custom Field for the Remote Issue Key
  • Creating a custom field (e.g., Exalate Remote Issue Key) and populating it via the incoming sync rule is the recommended and supported method.
  • Your script is correct:
    issue.customFields."Exalate Remote Issue Key".value = replica.key
  • To handle cases where the remote issue key is not available at creation, you can use syncBackAfterProcessing() to trigger a sync back once the remote issue is created, ensuring the key is updated.
  • This approach enables you to build dashboards showing both local and remote keys, along with other statuses.
  • Reference: Syncing remote issue keys and syncBackAfterProcessing() usage.

If you need code samples for any of these scripts, let me know which part you’d like to see in detail!