Customer Request Type Synchronization does not work

General Questions
, , ,
1

Originally asked by Dominik Blum on 12 October 2020 (original question)

Hi all,

We want to synchronize the customer request type from system A to system B, but instead of setting the new customer request type only the old value is removed in system B.

I used log.info to find out what is going wrong but the only thing I’ve found out

replica.customFields."Customer Request Type".value

and

issue.customFields."Customer Request Type".value

are identical on a system. But the value differs from system A to system B.

Below find all details that may help:

System A:

Service Desk version: 4.12.2

Jira version: 8.12.2

Exalate version: 5.0.3-j8

Outgoing rule on system A: replica.customFields.“Customer Request Type” = issue.customFields.“Customer Request Type”

System B:

Service Desk version: 4.7.1

Jira version: 8.7.1

Exalate version: 5.0.3-j8

Incoming rule on system B: issue.customFields.“Customer Request Type”.value = replica.customFields.“Customer Request Type”.value

If I use the ids instead in my incoming rule the synchronization works as expected:

switch(replica.customFields."Customer Request Type".value) {
    case "sdc1/98f72ad7-cd15-401a-9eb7-e0b303345e1d": 
        issue.customFields."Customer Request Type".value = "Request a New Feature"
        break;
    case "sdc1/f585e8bb-b9ae-40da-b1ef-5343d57c0cf8": 
        issue.customFields."Customer Request Type".value = "Improve Functionality"
        break;
}

But I don’t want to use such hard coded values as this would mean we need to edit the sync rules when adding new request types in both systems.

Best regards,

Dominik

Comments:

Michiel Meurs commented on 13 October 2020

Hi Dominik Blum,

Atlassian has only just enabled this feature and we’re working on a way to improve it. For now, using the ID’s is the way to go. An improvement has been raised for our Dev team.

Dominik Blum commented on 14 October 2020

Thanks for the information Michiel Meurs

2

Answer by Hung Nguyen on 12 October 2020

I assume that you had the same list of values for Customer Request type on both side. Then your switch case should be replaced by this line:

issue.customFields."Customer Request Type".value = nodeHelper.getOption(issue, "Customer Request Type", replica.customFields."Customer Request Type"?.value?.value)

The nodeHelpers.getOption would help you to find a match on your side for the same option value on your side

Comments:

Dominik Blum commented on 13 October 2020

Hi Hung Nguyen,

Yes, you are right. I have the same values for the “Customer Request Type” on both sides.

But there is a problem with your solution. I get always following error:

Script error for issue SDC1-49. Details: Sync rules include the property that does not exist. Details: No such property: value for class: com.exalate.basic.domain.hubobject.v1.BasicHubVpOrigin. Error line: Script65.groovy:116

I assume the value.value is not available for the “Customer Request Type” as following code leads to the error above:

log.info("Customer Request Type value.value " + replica.customFields."Customer Request Type"?.value?.value) // Does not work

But the same code without the second .value works as expected:

log.info("Customer Request Type value " + replica.customFields."Customer Request Type"?.value) // Works

With another custom field with type list your solution works as expected but not with the Jira Service Desk custom field “Customer Request Type”

Hung Nguyen commented on 14 October 2020

Are you using JIRA Cloud ?

Hung Nguyen commented on 14 October 2020

Can you change the rule to:

issue.customFields."Customer Request Type".value = nodeHelper.getOption(issue, "Customer Request Type", replica.customFields."Customer Request Type"?.value)
Dominik Blum commented on 15 October 2020

I’m using Jira server.

Your rule

issue.customFields."Customer Request Type".value = nodeHelper.getOption(issue, "Customer Request Type", replica.customFields."Customer Request Type"?.value)

leads to following error:

Script error for issue SDC1-51. Details: No signature of method: com.exalate.node.hubobject.v1_3.NodeHelper.getOption() is applicable for argument types: (com.exalate.basic.domain.hubobject.v1.BasicHubIssue, java.lang.String, com.exalate.basic.domain.hubobject.v1.BasicHubVpOrigin) values: [[], Customer Request Type, sdc1/9fa7bdb3-6565-4b26-bec1-dc963f55083f] Possible solutions: getOption(com.exalate.api.domain.hubobject.v1_16.IHubIssue, java.lang.String, java.lang.String), getOption(com.exalate.api.domain.hubobject.v1_16.IHubIssue, java.lang.Long, java.lang.String), getOptions(com.exalate.api.domain.hubobject.v1_16.IHubIssue, java.lang.String, java.util.List), getOptions(com.exalate.api.domain.hubobject.v1_16.IHubIssue, java.lang.Long, java.util.List). Error line: Script104.groovy:31

Michiel Meurs mentioned that there is currently not other solution than using the ids.