I’m getting errors on my 2 custom fields. I’ve checked the JIRA issue I wish to replicate and it does have values for each field. I should mention that these custom fields are both Select List, Single choice field types. I followed the doc for custom fields, do I need to do something different?
The sync comes back with **Error type:**Incoming script error - Cannot get property ‘value’ on null object. I checked the local payload screen and there I see both “customFields” and “customKeys” set to : {}. Do I need to do something different on either side?
Which you will need to do to unblock that current blocked sync.
Comments:
Lorraine Gorman commented on 10 December 2020
Thank you for your reply. It seems now I’m getting a different error that the 2 fields are required. So something is not working on the sending side in my outgoing sync using this (I would guess). Is this the correct format?
If you go to the Sync Queue, you will see all the queues of sync for the issue, for each of them you can see the content of the remote replica. Could you check if the custom fields are empty even for the last replica you have there?
To remove the error for existing sync that didn’t contain the values, you can click on “Ignore related sync” on the error actions. You will need to do it for every incoming sync without the required field.
Lorraine Gorman commented on 11 December 2020
I cleared all the errors and previous errors. In my test instance I made these 2 fields optional just to see if that would get a created issue. Now I have a similar error with Affected Version, which is also required for the issue type. The error is “You must set an Affects Version to create this type of issue…”. I went to the Sync Queue and I see the remote entity payload has values for both custom fields and also the affected Version values. But I still get the error and an issue is not created. Any other ideas?
Francis Martens (Exalate) commented on 16 December 2020
Is the incoming sync script on the side where the error occurs setting the affected version?
Lorraine Gorman commented on 17 December 2020
When I look at the incoming sync queue and then details of the remote payload, the affected Versions is populated.
Lorraine Gorman commented on 17 December 2020
To close up on this issue, the problem was not in the Exalate scripts but in the JIRA workflow Create Issue. I needed to remove a validation step and then the sync was no longer blocked. Thanks everyone for your help!
Francis Martens (Exalate) commented on 18 December 2020