Internal comments cannot be processed

General Questions
,
1

Originally asked by George on 19 March 2021 (original question)

We have a connection between Jira Cloud Service Management ↔ Jira Server Business Project.

It was working fine and suddenly we get this error on the Jira Cloud:

“Internal comments cannot be processed. The reason is: Request Type custom field is required, but not set…”

We followed some of the examples and configured the below in the incoming connection on the Cloud’s side:

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

if (!replica.status.equals(previous?.status)) {
  // construct the comment
  String message = "${replica.key}: Status updated from '${previous?.status?.name}' to '${replica?.status?.name}'"
  issue.comments = commentHelper.addComment(message, issue.comments)
}

The first line is to flag the comments received from the server as internal

and then the if block, to log status changes in the comments.

If we comment out the above lines it works.

Also we have a replica connection for test purposes which works fine and also for a couple of weeks it was working fine.

Could you please advise what could be wrong?

2

Answer by Francis Martens (Exalate) on 21 March 2021

Jira Service Management requires the request type to be set.
It could be that for that one particular issue, this custom field is not set and hence the trouble.

168×304 6.51 KB

Comments:

George commented on 22 March 2021

Thank you Francis Martens (Exalate)

Indeed some of the issues are without the Request Type and as I can see there is an open discussion on Jira’s community about setting the default value or using automation to fill that in which are still under review. General advice I can find is to use “Raise Request” instead of using “Create”.

I tried to set the below at the very top of the connection configuration, to update this field using Exalate, but it doesn’t seem to work.

Could you please advise why the following condition doesn’t work?

if (issue.customFields."Request Type"?.value == null || !issue.customFields."Request Type"?.value) {
    issue.customFields."Request Type".value = "General Support"
}

It returns the same error “Internal comments cannot be processed. The reason is: Request Type custom field is required, but not set…”

Francis Martens (Exalate) commented on 22 March 2021

The trouble is that the request type needs to be set before the internal comment can be applied.

Can you first try to set the internal comment on an issue which has the request type set and confirm that that works

George commented on 22 March 2021

Yes, it works for issues with requests types.

Francis Martens (Exalate) commented on 22 March 2021

OK - whenever you create a new issue on the service desk - is the code to set the customer request type available?

George commented on 31 March 2021

Agents are using the Create button and the default option is “Issue Type” e.g Support.

Could you please explain a bit more about the “code” because I didn’t fully understand that part?

Francis Martens (Exalate) commented on 31 March 2021

The customer request type is different from the issue type

About the code - is the customer request type being set in the issue

George commented on 31 March 2021

The customer request type is different from the issue type

Yes, we haven’t found a way to separate those on the “Create Issue” form. Jira keeps putting “Issue Types” and “Requests Types” in the same list.

About the code - is the customer request type being set in the issue

We asked the agents to set “Request Type” but we have 1 or 2 tickets per week which leave the “Request Type” blank, causing Exalate sync to break.

Question is whether there is a way around using Exalate, to auto-complete this but as I understood from your previous comment, it is not possible to set the request type and comments at the same time. Pleased to know if there is anything else we can try.

Francis Martens (Exalate) commented on 31 March 2021

You can set the request type at the moment the issue is created (in the firstsync).
If you skip adding the internal comments (until we provide a fix) during the firstsync, these will be added during the next sync.