3
2
1

Hi Exalate Community,


I have been working to create a sync between Jira Service Desk (cloud) and Zendesk service desks that is capable of synchronizing comments with the correct visibility. Currently I have a script in place that pulls all comments from zendesk into Jira as internal comments, but it is not capable of differentiating between public and private comments or doing a two-way sync of comments.


I've been working with support on this and they asked me to open a Community thread so that we can better track the effort put in, so here we are.


Currently I have attempted to use the scripts from https://docs.idalko.com/exalate/display/ED/How+to+manage+comment+visibility but haven't been able to get it working yet.

    CommentAdd your comment...

    3 answers

    1.  
      2
      1
      0

      Hi Stephen Wein, we have found a solution.

      Out of the box, Exalate will sync a public comment as public on both ends and internal comment as an internal comment on both ends. 

      The reason as to why your comments are not syncing as public/internal is because, in Jira Service Desk, you can only have Internal/Public comments, if the "Request Type" field is set. If the "Request Type" field is not set, the comment will not sync. 

      Retrieve the "Request Type" custom field.


      "customfield_10115" is the "Request Type" custom field.
      The name of this field can vary based on your environment. To find out the name of this field you need to go to:

      https://yourcompany.atlassian.net/secure/admin/ViewCustomFields.jspa?page=1&searchFilter=Request%20type

      There you will have a screen similar to this one: 

      Next, you click on "View field information". You will be redirected and the URL in your search bar will change to something like this:

      https://idalko.atlassian.net/secure/admin/ConfigureCustomField!default.jspa?customFieldId=10115

      At the end of the URL, we see the ID of this field. Note down this value, as you will need it later in the incoming sync.

      Retrieve the ID of the Request Type value.

      The next ID we need would be the ID of the (warning) value of the "Request Type. To check this, we would need to do a REST call. This REST call will return all possible and non-possible Request Types

      https://yourcompany.atlassian.net/rest/servicedesk/1/servicedesk/request/25366/request-types


      In this REST Request, you see the value 25366. This is the ID of the issue. To find this, go to an issue in your project, click the three-dot menu, and hover over one of the options like "Move". In the bottom left corner of your screen, you will see the ID of the issue. Now take this value and place it into the request from above.




      This REST Request will look similar to this:

      {
          "validRequestTypes": [
              {
                  "id": 188,
                  "cvId": 16,
                  "portalKey": "mipr",
                  "portalId": 16,
                  "key": "3a0574ec-a751-4674-a1ff-170ad164ac29",
                  "icon": 10432,
                  "iconUrl": "https://idalko.atlassian.net/secure/viewavatar?avatarType=SD_REQTYPE&avatarId=10432",
                  "issueType": 10101,
                  "issueTypeIconUrl": "/secure/viewavatar?size=medium&avatarId=10318&avatarType=issuetype",
                  "createScreenId": 0,
                  "viewScreenId": 0,
                  "issueTypeName": "Task",
                  "name": "Bananas",
                  "description": "",
                  "descriptionHtml": "",
                  "helpText": "",
                  "helpTextHtml": "",
                  "order": 0,
                  "usedByEmailSettings": false,
                  "groups": [
                      {
                          "id": 49,
                          "name": "General"
                      }
                  ],
                  "practices": []
              }


      From this request, we need to keep 2 values.

      The first value is the "portalKey", in our case "mipr"
      The second value is the "key", in our case "3a0574ec-a751-4674-a1ff-170ad164ac29"


      Finalization


      Now we have all the values that we need. if we fill in these values in the incoming sync script that I placed above, we will be able to sync both internal and public comments.


      Incoming sync
      if(!issue."Request Type")
      httpClient.put("/rest/api/2/issue/${issue.key}", """{
          "fields": {
              "customfield_10115": "mipr/3a0574ec-a751-4674-a1ff-170ad164ac29"
          }
      }""")


      • "customfield_10115" → the ID of the "Request Type" field
      • "mipr/3a0574ec-a751-4674-a1ff-170ad164ac29" is the portal key, followed by the key of the Request Type
        CommentAdd your comment...
      1.  
        1
        0
        -1

        The accepted response worked for us.


        I pulled the Request Type ID from the custom field as described, then ran the REST call by entering the provided URL with the 'yourcompany' portion replaced with the correct domain, and used the key and portal key from the response along with the request type ID to fill in the script provided. Comments sync with the correct visibility now in either direction.

        1. Michiel Meurs

          I am glad to hear your problem has been solved. It was an interesting one (big grin) 

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

        Hi Stephen Wein,


        I will get back to you on monday.


        Have a nice weekend,

        Michiel

          CommentAdd your comment...