New! Restrict your internal notes to project roles or groups

[Erki Tammik]

@Sarah Campbell is there a way to set a default role for internal comments? The current solution is error-prone because users can forget to add the role using the lock button.

I noticed that automation rules still have two comment visibility options 'Internal' or 'Share with a customer.' This feature is currently incomplete.

Does anyone else know a good workaround for this?

[Kevin Gérard]

Hi, 
I'm wondering if more people think this feature is insuffisient. 

I have an IT project, internal service desk style. 
My 'customers' thus are colleagues, they have browser permissions. 
so i need to expect from my IT colleagues to add internal command, and set a restriction for every internal comment? 

There's a big difference in the context of internal / external comments on an Internal service desk and External service desk. 

External service desk: non-agents should ONLY be able to set INTERNAL comments 

Internal service desk: non-agents should ONLY be abe to set PUBLIC comments.

if i propose this feature to my teams, they'll be after my head... 

[Jan Frischmuth]

For me, this feature is a little broken. I'm using the Scriptrunner add-on as a listener for the comments in a project and whenever a comment is both internal and restricted to a certain rule, the Scriptrunner can't access the comment.

Let's say there are two "normal" comments in an issue and someone writes a third comment and restricts it to a project role. Then the script listener will be activated as it can hear the fired event but then it only sees the first two comments.

I'd suggest to open up the visibility for add-ons (my preference) or to work on the event listening to make it more cohesive. Right now, it's a mix of both.

Previously, I opened a community question because of this odd behaviour
https://community.atlassian.com/forums/Jira-Service-Management/Incomplete-API-Response-when-Internal-Comment-is-restricted-to/qaq-p/2887713