Questions for Confluence license has expired.

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

Unable to change comment visibility in Jira Service Management

 
1
0
-1

We have two Jira Service Management instances (A and B) and the following problem:


1) Create public comment X in instance B
2) Exalate synchronizes public comment X to A
3) See X in portal
4) Change visibility of X to internal by editing it in instance B and clicking „Add to issue only“
5) X is marked „Internal“ in instance B
6) Exalate synchronizes something


Expected result:
X is marked „Internal“ in instance A

Actual result:
X is not marked „Internal“ in instance A

The behaviour is equivalent if we change the visibility from internal to public.


The outgoing code for B and the incoming code for A is attached below.


Does anybody have an idea what could be the problem?


A_incoming.txt

B_outgoing.txt

  1. Ariel Aguilar

    Hi there,

    Can you make sure you are synchronizing customer request type, you may see more information here:

    https://docs.idalko.com/exalate/x/hIYrAQ

    Once you do, you may check the comment visibility again.

    Kind regards,

    Ariel

  2. Elias Bichler

    Hi,


    the link you provided does not work (I guess it references an internal confluence area, where I do not have access to). Instead I had a look at https://docs.idalko.com/exalate/display/ED/Jira+on-premise%3A+How+to+sync+Customer+request+type+field+in+Jira+Service+Desk and tried to use that approach. Unfortunately, this doesn't work, either.  issue.customFields."Customer Request Type"  returns the following:


    "Customer Request Type": {
        "value": {
            "serviceDeskProjectKey": null,
            "requestTypeKey": "750ceee5-8b14-47fd-8eb4-f213b25dfe21",
            "serviceDeskProjectName": null,
            "serviceDeskId": null,
            "representationValue": "et/750ceee5-8b14-47fd-8eb4-f213b25dfe21",
            "requestTypeName": null,
            "requestTypeId": null,
            "portalKey": "et"
        },
        "type": "VP_ORIGIN",
        "uid": "10001",
        "id": 10001,
        "locked": false,
        "description": "Holds information about which Service Desk was used to create a ticket. This custom field is created programmatically and must not be modified.",
        "name": "Customer Request Type"
    }



    As you can see, "requestTypeName" is null. Do you have any idea?


    Regards,

    Elias

  3. Ariel Aguilar

    Hi Elias,

    This is the one I was referring to: https://docs.idalko.com/exalate/x/1gF1Aw

    You should be able to see it now.

    Kind regards,

    Ariel

  4. Elias Bichler

    Hello Ariel,


    thanks for mentioning this new page. I already did, what is described there. The result can be seen in my comment above, however I will add it here as well:


    issue.customFields."Customer Request Type"  in the sending instance returns the following:


    "Customer Request Type": {
        "value": {
            "serviceDeskProjectKey": null,
            "requestTypeKey": "750ceee5-8b14-47fd-8eb4-f213b25dfe21",
            "serviceDeskProjectName": null,
            "serviceDeskId": null,
            "representationValue": "et/750ceee5-8b14-47fd-8eb4-f213b25dfe21",
            "requestTypeName": null,
            "requestTypeId": null,
            "portalKey": "et"
        },
        "type": "VP_ORIGIN",
        "uid": "10001",
        "id": 10001,
        "locked": false,
        "description": "Holds information about which Service Desk was used to create a ticket. This custom field is created programmatically and must not be modified.",
        "name": "Customer Request Type"
    }


    As you can see, value of the key "requestTypeName" is null, meaning that I'm not able to extract any information for retrieving the customer request type. Therefore I cannot send any information regarding the customer request type to the receiving instance. Is this a bug of the plugin?


    Kind regards,

    Elias

  5. Ariel Aguilar

    The documentation suggests the following:

    Outgoing from source side:

    replica.customFields."Customer Request Type"   = issue.customFields."Customer Request Type"

    Incoming destination side:

    issue.customFields."Customer Request Type".value =  "IT Help"

    Basically, the request type value is manually added.

    Ariel

  6. Elias Bichler

    Hello,


    maybe I'm missing out something but why would I need to set the outgoing sync, if I should hardcode the incoming part? Basically, the outgoing information isn't used at all with this approach. Anyway, unfortunately setting the Customer Request Type manually does not fix the actual issue with the visibility of comments not being synchronized.

  7. Ariel Aguilar

    Hi Elias,

    Is the customer request type set? Then, what code is used for the comment visibility?

    Kind regards,

    Ariel

  8. Elias Bichler

    Hi Ariel,


    the code is follows:


    Outgoing (Instance B): 

    replica.comments       = issue.comments


    Incoming (Instance A): 

    issue.comments     = commentHelper.mergeComments(issue, replica, {it})


    Kind regards,

    Elias 

CommentAdd your comment...

1 answer

  1.  
    1
    0
    -1

    Try the following incoming:

    issue.comments = commentHelper.mergeComments(issue, replica, {
      comment ->
      if (comment.internal) {
	  comment.internal = true
      comment
      } else{
      comment
      }
	} 
)
      CommentAdd your comment...