The Exalate team will be on holiday for the coming days - returning Jan 4
Enjoy & stay safe
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.
Can you look at all the differences between the issues where it succeeded and where it failed. There might be a pattern?
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?
What error did/do you get?
Bad news, Epic.send and Epic.receive methods are not supported for next gen projects. Could you try this instead:
replica.parentId = issue.parentId
issue.parentId = syncHelper.getLocalIssueKeyFromRemoteId(replica.parentId)?.id
That should ensure that the Epic Link relation is synced over. Let me know how it goes.
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.
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.
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.
© 2019 Exalate. All rights reserved.