1
0
-1

We are using an exalate plugin to sync records between cloud instance and server instance of Jira Service Desk. facing issue in syncing request type custom field ( customer request type in server). guide us with the steps to follow

    CommentAdd your comment...

    4 answers

    1.  
      1
      0
      -1

      Hi Roshan vislavth,


      I took a fresh look at this issue and here are my findings:


      • The Request Type field can be set without issue using Exalate, but this only works when the issue is being newly created i.e. when you first Exalate a ticket and it creates a twin issue on the other side, the Request Type should work successfully. In order to do this, please use the following:
        Outgoing sync script (on the sending side):
        replica.customFields."Request Type" = issue.customFields."Request Type"
        Incoming sync script (on the receiving side):
        issue.customFields."Request Type".value = replica.customFields."Request Type".value.requestTypeName


      • The issue arises when you update the Request Type field on the source side and it does not sync over to the other side. This is due to a limitation in the Jira API whereby updates to this field are not allowed via the API i.e. you can only use the API successfully at issue create time, but not while updating it. I have attached a video explanation on the subject as well herewith. 


      • As the API would not allow to change the Request Type after the issue has been created, you need to think about workarounds to this. One possibility could be to use a custom field to control this and then have an automation set within Jira which would select the correct Request Type based on the value of that custom field. You will be able to sync that custom field using Exalate and can use a similar automation on the other end too. I appreciate that this is extra work but it is a constraint on the Jira end which we have to work around unfortunately. 


      I hope this clarifies the situation for you. 


      Thanks

      Majid

        CommentAdd your comment...
      1.  
        1
        0
        -1

        I think in some JSM versions the field is "Customer Request Type". I'm pretty sure it is "Request Type" in the current cloud version, but it might be called "Customer Request Type" in your server instance. (I'm pretty new to Exalate. We're still just trialing the plugin.) 

          CommentAdd your comment...
        1.  
          1
          0
          -1

          We are getting the below error 


            CommentAdd your comment...
          1.  
            1
            0
            -1

            We are connecting two JSM instances using the visual mode. Adding the following script worked for us. 


            if (firstSync) {

                    issue.customFields."Request Type".value = replica.customFields."Request Type".value.requestTypeName

            }

            1. Roshan vislavth

              Hello Matt, 

              thanks for quick response, i see this error in the Request type line in the script. 

            2. Harold Oconitrillo

              Hi Roshan vislavth,


              Can you please confirm if you are using the scripts described in the documentation?

              https://docs.idalko.com/exalate/x/1AF1Aw

              https://docs.idalko.com/exalate/x/1gF1Aw


              Kind regards,

              Harold Cruz

            3. Roshan vislavth

              Yes we are using the same script as described still same error "Error Line:20"

            4. Roshan vislavth

              Source: Jira Service Desk cloud 

              Destination: Jira Service Desk Server version 4.19.1


              The above script provided by you seems to be working(not getting error messages) but in the destination issue the request type is not matching or not found (we see the same Request type label available for the issue type in both source and destination)


              let us know if you need additional information to guide us.


              Thank you,

              Roshan.

            CommentAdd your comment...