Summary

A customer received a notification from a JSM (Jira Service Management) ticket about a comment even though the comment was added internally by an agent.

The purpose of this KB article is to list the possible scenarios where this behavior might happen, and how to identify them.

Environment

Any Jira Service Management (JSM) Server/Data Center version from 3.0.0.

Scenarios

Scenario 1 - the agent added the comment as a public comment by mistake, and later changed it to an internal comment

Scenario details

Even though the comment is showing as internal in a JSM ticket, it is possible that the agent who added this comment added it first as a public comment by using the button Share with customer, then realize the mistake and edited the comment to make it internal.

In such case, the customer will receive a JSM customer notification of type Public Comment Added, since the comment was public at first.

How to identify this scenario

It is very difficult to verify if the notification was sent for this specific reason, since there will be no indication in the JSM ticket (or the Jira logs) that the comment was first added as "public" before being made "internal":

• if the agent made the comment public at first and then internal without changing the content of the comment, there will not be any edited flag next to the comment
• however, if the agent made the comment public at first and then internal while changing the content of the comment, then there will an edited flag next to the comment
  

In the case the agent made the comment internal after making it public without changing the content of the comment, there will not be any edited flag next to the comment, so it is not possible to tell from the UI if the agent made a change to the comment or not (whether the visibility was changed or the content). For this specific case, the only way to tell if an agent made some change to a comment (by changing its visibility or by changing its content) is to check the Tomcat Access logs.

Let's assume that:

• You have a JSM ticket in your Jira application, with ID 14624
  •  Note that it is not the Issue key, but the issue ID that can be found by hovering over the Edit button from the issue view page and checking the ID at the end of the URL.
  • For example: <JIRA_BASE_URL>/secure/EditIssue!default.jspa?id=14624
• The comment that was added to this Jira issue has the ID 13700
  •  The comment ID can be found by hovering over the comment link and checking the ID in the URL.
  • For example: <JIRA_BASE_URL>/browse/SDBASIC-100?focusedCommentId=13700&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13700

The HTTP requests sent from the browser will look like the below, depending on the action made in the ticket:

• If a new comment is added using the Share with customer button, the request will look like this:
  • URL: POST <JIRA_BASE_URL>/rest/api/2/issue/14624/comment
  • Payload:

    {"body":"adding a public comment here","properties":[{"key":"sd.public.comment","value":{"internal":false}}]}
    

• If a new comment is added using the Comment internally button, the request will look like this:
  • URL: POST <JIRA_BASE_URL>/rest/api/2/issue/14624/comment
  • Payload:

    {"body":"adding an internal comment","properties":[{"key":"sd.public.comment","value":{"internal":true}}]}
    

• If an existing comment is edited (either by changing the text, or by changing the visibility of the comment), the request will look like this:
  • URL: PUT <JIRA_BASE_URL>/rest/api/2/issue/14624/comment/13700
  • Payload

    {"body":"Test with public comment, later made internal","properties":[{"key":"sd.public.comment","value":{"internal":true}}],"visibility":{}}
    

By checking the Tomcat Access Logs which are stored in the directory <JIRA_INSTALL>/logs, and which have the format access_log.<date>.log, you might be able to spot these requests, provided that you get the Issue ID first, and then grep for "issue/<issue_id>/comment" in the logs. Even though the Tomcat access logs only show the URL and method without the payload, you might at least be able to check if the comment was edited at some point (with the PUT method). However, since the logs do not content the Payload, it will not be possible to tell what exact change was made to the comment, and if the change was related to the comment visibility or the comment content itself.

Example of entry found in the Tomcat Access Logs showing that a comment was edited in a JSM ticket (issue ID 14624, comment ID 13700):

0:0:0:0:0:0:0:1 863x3152x1 julien [13/Jul/2023:14:23:10 +0200] "PUT /jira8201/rest/api/2/issue/14624/comment/13700- HTTP/1.1" 200 425 150 "http://localhost:8081/jira8201/browse/SDBASIC-100?jql=" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36" "gz2spn"

Scenario 2 - Bug JSDSERVER-6269

Scenario details

If the customer is both a watcher and a participant of a JSM ticket, this customer will receive a notification from an internal comment, if this customer was @-mentioned in the comment, due to the bug tracked in https://jira.atlassian.com/browse/JSDSERVER-6269.

In such case, the customer will received the Jira core notification of type user mention, instead of a customer notification.

How to identify this scenario

To check if this scenario applies, you can check the following points:

• the notification received by the customer needs to be a Jira core notification of type user mention, instead of a customer notification
• if you check the JSM ticket from which the customer received the notification, you should see that:
  • the customer is both a watcher of the ticket, and also part of the Request Participants field
  • the customer was mentioned in a comment added to the ticket