CustomField mapping problems

Hello,

we have a problem with the synchronization between two custom fields from the remote instance to our local. One field is a single line text field, the other a select list (single choice). In both instances, the value of the remote fields aren’t synchronized to our local issues or more specifically are only returning “null” values (when trying to print the value to the log).

The problem of not receiving the value of a specific custom field also appears in another connection with the same custom text field on the remote side. As this other project resides in our Jira Software instance, I attached the support zip from this one.
The fields we are trying to sync are named as followed:

Local:
.) Name: Kundenreferenz
.) ID: 12820

Remote:
.) Name: Kundenreferenz
.) ID: 10087

Thanks

Hi @Martin_Bosano,

Could you please share your current synchronization rules from both sides of the connection so I can take a look?

Thanks!

Have you inspected the payload (remote replica) on the receiving instance to see what you are receiving. This will help narrow down the problem to the “sending” or “receiving” side. Please also share the scripts you are using to accomplish this.

Thanks
Majid

Hi,

as this request was created on my behalf, I’m providing the requested information.

@Javier This is the configuration of the single line text field on both sides:
Outgoing:
replica.customFields."12820" = issue.customFields."10087“

Incoming:
issue.customFields."12820" = replica.customFields."10087"?.value

@Majid I inspected the payload we are receiving from the replica. I can confirm that we are receiving the value from this field, but somehow aren’t able map it to a text field or print it to the logs.

Remote Payload:
"customFields": {
"12820": {
"id": 10087,
"name": "Kundenreferenz",
"uid": "10087",
"type": "STRING",
"value": "MAKS-468"
}

Best regards

So the value is received i.e. MAKS-468
Then the problem is on the receiving end (I would only tinker with the scripts there).

Provided you are trying to assign it to the XYZ custom field on receiver, the correct way would be (based on your payload):

issue.customFields.“XYZ”.value = replica.customFields.“12820”.value

Hope it helps.

Thanks
Majid

Hello @Majid,

we now have tried this approach, but had to swap the IDs of the custom fields because “12820” is the field on our instance. We are trying to get the value from the custom field with the ID “10087” on the remote instance.

When we then triggered an update from the remote instance, we received the error “Cannot get property ‘value’ on null object” from that line. However, when inspecting the remote issue tab as well as the remote payload, the value is visible.

Thank you for your help

Can you paste the part of the replica payload where you see the value received (provide the full structure of the field).
Thanks

Hi @Majid,

if I understand correctly, this must be the part you are looking for:
"customFields": {
"12820": {
"id": 10087,
"name": "Kundenreferenz",
"uid": "10087",
"type": "STRING",
"value": "MAKS-575"
}

(The value changed because I took the payload of another issue)

Best regards

Ok, so this looks like the correct remote payload and the field name in replica is 12820.
That means you are definitely sending 12820 from the remote side.

So, this line should still work on your side:
issue.customFields.“XYZ”.value = replica.customFields.“12820”.value

I would also recommend watching this quick video.

If this doesnt help, please send me the exact line you have in your incoming.

Thanks
Majid

2 Likes

Did you manage to resolve this please?

Hello,

it’s working now. I found the solution in the provided video.
I didn’t know that the left side ID of the outgoing script needs to match with the right side ID of the incoming script. Also that, in the outgoing script, it didn’t need to be the field we are using on the local instance.

Thank you for your help.

Best regards

1 Like

Glad to hear!! Thanks for the update.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.