Ncoming sync fails on Closed issues after adding jira.issue.editable=false workflow property (Jira Cloud)

General Questions
1

Hi everyone,

Environment: Jira Cloud, Exalate with scripted synchronization (Groovy)

Context

In my incoming sync script, I skip any update when the local issue is already Closed:
if (issue.status.name == "Closed") {
return
}

This worked as expected: as soon as the script detected a Closed issue, it skipped the sync and exited.

Problem

Recently, we modified the workflow of the affected issues by adding a step property to block editing of Closed issues (jira.issue.editable = false). Since that change, the synchronization fails with the following error:

Could not update work item JIRA-4979 with id 52120:
Field customfield_11028: Field 'customfield_11028' cannot be set. It is not on the appropriate screen, or unknown.;
Field components: Field 'components' cannot be set. It is not on the appropriate screen, or unknown.;
Field versions: Field 'versions' cannot be set. It is not on the appropriate screen, or unknown.;
Field labels: Field 'labels' cannot be set. It is not on the appropriate screen, or unknown.

Questions

  1. Why does the update still get attempted even though the script returns early when the status is “Closed”? Is Exalate applying some field changes outside of the incoming script logic?
  2. Is there a recommended way to make Exalate fully skip processing (not just the script body) for issues that are no longer editable?
  3. What is the best practice to combine jira.issue.editable = false with Exalate synchronization?

Thanks in advance for your help!

2

Great questions! Here’s what’s happening and how to address it:

  1. Why does Exalate still attempt updates after your early return?
    Even if your incoming sync script returns early, Exalate may still process certain system fields (like status, resolution, or other mapped fields) outside your script logic. This is because Exalate’s sync engine handles some updates before or after the script runs, especially for fields that are part of the core synchronization configuration. That’s why you’re seeing errors about fields that can’t be set when the issue is not editable.

  2. How to fully skip processing for non-editable issues?
    To prevent Exalate from attempting any updates, you can use the skipOutcomingSync and skipIncomingSync flags in your script. For your scenario, set skipIncomingSync = true at the very top of your incoming sync script when the issue is closed. For example:

if (issue.status.name == "Closed") {
    skipIncomingSync = true
    return
}

This tells Exalate to skip all processing for that sync event, not just the script body.

  1. Best practice for combining jira.issue.editable = false with Exalate
    When you use jira.issue.editable = false, make sure your sync scripts are aware of this restriction and use the skip flags as above. This prevents Exalate from trying to update issues that are locked by workflow properties. It’s also a good idea to document this in your team’s sync configuration so everyone is aware of the interaction.

Summary:

  • Exalate may process some fields outside your script, leading to errors if the issue is not editable.
  • Use skipIncomingSync = true in your script to fully skip processing for closed (non-editable) issues.
  • Always align your workflow properties and sync scripts to avoid conflicts.

You can find more details in the official documentation on controlling synchronization with skip flags.

Hope this helps you keep your syncs smooth and error-free!

3

Unfortunately, I applied the proposed change and I’m still getting exactly the same error
The behavior is unchanged: the incoming sync still tries to update the fields even though the issue is Closed and no longer editable.

4

Hi @ouejhani_makram

Can you please try this?

  if (!nodeHelper.isIssueEditable(issue)) {
      return new scala.Tuple2(issueKey, scala.collection.JavaConverters.asScalaBuffer(traces))
  }

Let me know in case of any further assistance.

Thanks,

Sonal

5

Thanks @Sonal_Otwani for your suggestion. Unfortunately, after testing it, the proposed solution did not resolve the issue on my side

Thanks

6

Hi @ouejhani_makram

Can you please let me know what do you mean by solution did not work?

Is it giving any error or it is still trying to update the Jira ticket?

Thanks,

Sonal

7

Hi @ouejhani_makram

Please provide your target Jira URL.

Thanks,

Sonal