Unable to change comment visibility in Jira Service Management

General Questions
, , ,
1

Originally asked by Elias Bichler on 19 May 2022 (original question)

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 (old community)

B_outgoing.txt (old community)

Comments:

Ariel Aguilar commented on 19 May 2022

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

Elias Bichler commented on 31 May 2022

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

Ariel Aguilar commented on 31 May 2022

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

Elias Bichler commented on 01 June 2022

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

Ariel Aguilar commented on 02 June 2022

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

Elias Bichler commented on 07 June 2022

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.

Ariel Aguilar commented on 13 June 2022

Hi Elias,

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

Kind regards,

Ariel

Elias Bichler commented on 15 June 2022

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

2

Answer by Ariel Aguilar on 15 June 2022

Try the following incoming:

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