Questions for Confluence license has expired.

Please purchase a new license to continue using Questions for Confluence.

Customer Request Type Synchronization does not work

 
1
0
-1

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

  1. Michiel Meurs

    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.

  2. Dominik Blum

    Thanks for the information Michiel Meurs

CommentAdd your comment...

1 answer

  1.  
    1
    0
    -1

    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

    1. Dominik Blum

      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"

    2. Hung Nguyen

      Are you using JIRA Cloud ?

    3. Hung Nguyen

      Can you change the rule to:

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

      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.

    CommentAdd your comment...