JIRA Cloud sync fails because fields (summary, reporter, description) cannot be set

Originally asked by Jean-Francois Caouette on 27 November 2020 (original question)


I am attempting to synchronize a next-gen project between two JIRA Cloud instances. Approximately 60 out of 80 issues have synchronized correctly, but I am getting errors on the last 20 issues:

javax.script.ScriptException: services.jcloud.exception.IssueErrorCollectionException: Field Field 'summary' cannot be set. It is not on the appropriate screen, or unknown.: summary; Field Field 'description' cannot be set. It is not on the appropriate screen, or unknown.: description; Field Field 'reporter' cannot be set. It is not on the appropriate screen, or unknown.: reporter.

I am positive that those fields do exist on the screens, though unsure how this applies to a next-gen project. And a bit baffled that the synchronization worked for some of the issues, and not others. Does anyone have pointers? Thanks.


Answer by Francis Martens (Exalate) on 29 November 2020

Can you look at all the differences between the issues where it succeeded and where it failed. There might be a pattern?


Comments:

Jean-Francois Caouette commented on 30 November 2020

Thanks for the pointer, Francis.

On closer examination, it seems all the issues that are failing to synchronize have a parent (either an epic, or a parent task). The epics themselves have synchronized properly, but none of their children are going across.

I have the documented Epic.send() and Epic.receive() calls in the synchronization scripts. Synchronizing epics in a classic project gave us trouble because a custom field was missing from the epic screen on the target instance… I’m unclear how/where to configure this in a next-gen project. Should the scripts be configured differently?

Francis Martens (Exalate) commented on 01 December 2020

What error did/do you get?

Juan Grases commented on 01 December 2020

Hi!

Bad news, Epic.send and Epic.receive methods are not supported for next gen projects. Could you try this instead:

//Outgoing
replica.parentId = issue.parentId
//Incoming
issue.parentId = syncHelper.getLocalIssueKeyFromRemoteId(replica.parentId)?.id

That should ensure that the Epic Link relation is synced over. Let me know how it goes.

Jean-Francois Caouette commented on 14 December 2020

Thanks for the tip, Juan. I attempted to add the above to the incoming scripts in order to clear the error queue on the incoming instance. I assumed this would be enough, because the remote replica payload on the incoming instance already has a parentId, according to the error details. It didn’t help. I would probably have to clear the queue and re-sync with the outgoing script updated as well, though I’m not sure what that would change.

Our customer ended up copying the handful of un-synced issues by hand.

Answer by Juan Grases on 27 November 2020

Hi!

In my experience when you see a error message like that with so many fields, this is rather a permission problem. Check if the issue is set with some special security level which the Jira group for admin addons (atlassian-addons-admin) has no permissions.

Best regards,

Juan


Comments:

Jean-Francois Caouette commented on 28 November 2020

Thanks for the tip, Juan!

I cannot see any difference in security level between the issues that synchronized successfully and those that are failing. I’m also unclear on how to manage permissions for issues in a next-gen project, as the project doesn’t seem to be associated to any permission scheme on the Permission schemes dashboard.