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

General Questions
,
1

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.

2

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.

3

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.