Comment visibility not properly updated when created by an automation

[Tarik Ljouad]

Hello All,

I am currently trying to set an automation that handles a certain usecase where the ticket has to be closed upon creation. My workflow involves a mandatory comment before resolving the tickets. 

I tried adding a comment in the transition and it works perfectly fine. But the comment visibility is always set to Public, even though my automation is set to make an internal comment. Below is a snipet: 

{
"update": {
"comment": [
{
"add": {
"public": false,
"body": "Ticket automatically resolved upon creation"
}
}
]
}
}

[Andy Heinzer · Accepted solution]

Hi Tarik,

I understand that you are trying to use automation in Jira Cloud in order to add a private comment on an issue during a transition.  However I believe that the syntax you are using here appears to be specific to Jira Service Management projects (e.g. "public": false)  JSM has a different means to handle private/public comments than the rest of Jira does.  

That said, I believe I found a way to do this in both Jira Software and Jira Service Management projects using automation.

For Jira Service Management projects:

Instead of trying to make a comment in the transition that is private, try creating a separate action to add a comment to the issue first as a separate action.  When using the add a comment action in automation within a JSM project, there are different options presented and you can choose to make it public if you like, but in this case you can just leave that checkbox unchecked:

This approach can work.  But it is slightly different than trying to add a comment at the exact moment of the transition itself using the advanced json input of the More field.  If that is a concern here let me know, perhaps I can investigate further, but the problem I have come across here is that transitions of this nature do not always have complete access to the manner in which JSM handles internal versus public comments.  So it might not be possible in the current automation to manage this.  Strangely enough the Legacy Automation appears to be able to do this.

For Jira Software and Jira Core type Projects (Company managed):

There are a few things to check before making this work. JSM does this differently than other Jira project types. In my own automation action rule, under the transition action, there is the More options section where I entered the value of:

{
"update": {
"comment": [
{
"add": {
"body": "Thanks for raising {{issue.key}}.",
"visibility": {
"type": "role",
"value": "Developers"
}

}
}
]
}
}

In this case, my project has a role called Developers, AND I had to edit the rule details to make sure that this automation rule was had an Actor value of my account and not the Automation for Jira account.  This is because in order to make that kind of comment on the issue, you need to use a user account that is a member of that role.  Right now this Automation for Jira user account does not seem to be something you can add to that project role.

Once this was setup in this manner, I found that triggering this automation rule would correctly transition the issue and add that comment so it was only visible to users in the Developers role, like so:

Does this help?  Please let me know.

Andy

[Tarik Ljouad]

Hi @Andy Heinzer 

Thanks a lot for the swift and detailed analysis and feedback. Highly appreciated.

I am indeed raising this issue specifically for a JIRA Service Management Project, accepting (also automated) tickets by Emails.

Now this is my challenge: our workflow is designed in a way that a comment is required during the transition to a resolved state (with the idea that agents should not close a ticket with no proper feedback to the customer/reporter).

Therefore, the comment has to be added at the same time as the transition in the automation.

The comment has to remain internal for two reasons: 

- The reporter (in this case a partner) does not need to know what we did with the ticket. They raise it as a flag for us.

- Making it a public comment would eventually trigger a communication email towards the reporter's system as per the current notifications scheme, which would enter in an email loop.

Any ideas how this can be done? and any idea why the syntax "public": false" doesn't work here since I am running it in a JIRA Service Management project? 

[Andy Heinzer]

Thanks for the additional context here.  That helps. I took a deeper look at this and I believe the problem is regards to a known limitation of the REST API. 

I came across this feature request: JSDSERVER-5034  which indicates that it's not possible currently to use the REST API to make a transition AND post an internal Service Management comment in a single REST API call.  You certainly can make a transition and internal comment in a single action when in the web interface of Jira, however this works slightly different than the REST API functions.  It does not appear this is possible to manage via the REST API right now, and in turn I believe that automation is effectively bound to the same limitation here.

While that ticket is for JSM server, I believe the same limitation exists in our Cloud platform.  I also created a Cloud version of this same problem over in JSDCLOUD-9918.

In the meantime, perhaps we can take a closer look at the specific of the workflow here to find a solution.  Could you let me what is the specific condition/validator that is in use here?  There are a couple of different validators that I could be configured to restrict this kind of transition.  My line of thinking is that your workflow might have a validator such as 'Field has been modified Validator' but if you have admin access, you might be able to tweak this into a 'Field Required Validator' and still choose the Comment field.  This could still prevent transitions for issues without Comments, but then would not require it in the transition event itself.  This way you could create an automation rule with two distinct action (Comment first, and then transition).  Perhaps this could still make a working solution for adding internal comments and transitioning the issue automatically if not in the exact same event.

Andy

[Tarik Ljouad]

Unfortunately, this is already configured as 'Field Required Validator': 

[Andy Heinzer]

Hi @Tarik Ljouad 

Thanks for that info.  I took another look at this and while we cannot technically post a JSM internal comment during the transition in a single REST API call, we can still create a comment that has limited visibility along with the transition.

The thing to note here is that this visibility is not a JSM specific feature, but a broader Jira concept.  There is also a permissions/role aspect to consider for this kind of work around.  I will try to explain in more detail here.

In my instance I created a new automation rule, in this case with a manual trigger.  The action is just a transition issue, and in the additional fields I have the following json:

{
"update": {
"comment": [
{
"add": {
"body": "This message can only be seen by Service Desk Team members",
"visibility": {"type": "role", "value":"Service Desk Team"}
}
}
]
}
}

Things to note about this setup:

1. Only users in the "Service Desk Team" will be able to see that message.  As long as the customer is not a member of that role, they won't see this.
2. The automation rule will fail here if you leave the actor that runs this rule in the default "Automation for Jira" because that service account is not a member of that project role.  Essentially we need to make sure that the actor here is someone in that role.  In my screenshot I selected "User who triggered the event" because it was a manual and I knew who that would always be.  In your case, you will probably want to pick a specific user account that can run this rule instead since the user that triggered it might be a customer in your case, and ideally customers won't be in that role.

I tested this and found that my customer cannot see the message, but can see that their request has been resolved by this action.  Also everyone in the "Service Desk Team" role can still see that message.

I think this is probably the best work-around for the time being.  Of course you could create a different group name or project role that is specific to your environment, but I suspect that this one would exist in most JSM projects and would be expected to exclude any user that is only in the customer role.

Let me know if you have any questions about this setup.

Andy

[Tarik Ljouad]

You, my friend @Andy Heinzer , are a rockstar !!

Just when I started losing hope and surrendered to the idea of making a public comment, you came up with this brilliant workaround.

This worked like a charm! I just tested it with myself as an automation user, and restricted the view to the Administrators role (we are not that many). The comment was indeed hidden to non-admins, and the only email received by the reporter was about the transition to the resolved state. I will still have to think though about the ideal user to use on PROD.

Thank you again for the brilliant support!!