Originally asked by Andre Ponert on 23 August 2022 (original question)
Hello,
we sometimes have issues syncing the closed status on tickets. We use the GUI sync and also do the status sync as the very last in order.
However, we constantly get this error:
Issue is not editable error
Issue #ISSUE_KEY# on status Closed cannot be updated by user syncuser. Please check permissions.
We could not find out what happens here. Because in my opinion, if status is the last thing that is synced, it should not want to sync any other field AFTER it.
Here’s our sync configuration:
We can exclude, that it tries to sync changes on an already Closed issue, because our trigger is configured this way:
project in (PROJECT1, PROJECT2) and (fixVersion is not empty or assignee in membersOf("groupname") or creator in membersOf("groupname")) and status != Closed
Stacktrace:
com.exalate.api.node.exception.IssueNotEditableException: Issue STAERELTEC-1952 on status Closed cannot be updated by user syncuser. Please check permissions for user and if issue can be updated on status Closed at com.exalate.node.hubobject.v1_4.NodeHubIssueHelper.validateUpdate(NodeHubIssueHelper.java:322) at com.exalate.node.hubobject.v1_4.NodeHubIssueHelper.updateIssueWith(NodeHubIssueHelper.java:770) at com.exalate.compatibility.HubObjectHelperAdapter.updateNodeIssueWith(HubObjectHelperAdapter.java:61) at com.exalate.hubobject.v1_2.HubObjectHelper.updateNodeIssueWith(HubObjectHelper.java:345) at com.exalate.processor.jira.JiraChangeIssueProcessor.applyProcessorResult(JiraChangeIssueProcessor.java:311) at com.exalate.processor.jira.JiraChangeIssueProcessor.changeIssue(JiraChangeIssueProcessor.java:173) at com.exalate.replication.request.UpdateIssueSyncRequestState.transition(UpdateIssueSyncRequestState.java:118) at com.exalate.replication.request.UpdateIssueSyncRequestState.transition(UpdateIssueSyncRequestState.java:36) at com.exalate.replication.in.RequestProcessorService.processSyncRequest(RequestProcessorService.java:391) at com.exalate.replication.in.RequestProcessorService.processSyncRequestsWithPriorities(RequestProcessorService.java:186) at com.exalate.replication.in.RequestProcessorService.processSyncRequests(RequestProcessorService.java:136) at com.exalate.replication.in.RequestWorker.runProcessing(RequestWorker.java:32) at com.exalate.replication.ReplicationWorker.lambda$run$0(ReplicationWorker.java:85) at com.exalate.node.util.concurrent.ClusteredSensitiveExecutorService.lambda$executeHandlingLocks$0(ClusteredSensitiveExecutorService.java:31) at com.exalate.node.util.concurrent.ClusteredSensitiveExecutorService.executeHandlingLocks(ClusteredSensitiveExecutorService.java:52) at com.exalate.node.util.concurrent.ClusteredSensitiveExecutorService.executeHandlingLocks(ClusteredSensitiveExecutorService.java:29) at com.exalate.replication.ReplicationWorker.run(ReplicationWorker.java:78) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
So the error must occur, when it tries to sync changes and also has to close the issue afterwards. We do not want the user to be able to touch closed issues, so this would not be a solution to us.
What we already tried was adding a script to the top of the sync and tried several ideas from how to avoid error “Status: closed prevents ticket update” (old community) and related pages. Nothing worked, the error stays the same.
Also we updated the Exalate plugin in both instances to the latest version and did all the above again.
The Exalate Support referred us here to post this case.
We are looking forward to getting some assistance with our issue.
Regards,
André Ponert
Comments:
Harold Oconitrillo commented on 23 August 2022
Hi,
Which instances do you use?
Regards
Andre Ponert commented on 23 August 2022
Hi Harold,
Instance 1: Jira Server 8.13.22 with Exalate 5.3.9-j8
Instance 2: Jira Server8.20.10 with Exalate 5.3.9-j8
Was that your question?
Support commented on 05 September 2022
Hi Andres,
Yes, that was my question. Now, for this type of advanced configuration, I strongly recommend you to move on to scripted connection.
Best regards