I'm having a problem with a servicedesk (JSM) project where non-agents are getting internal comments sent to them in notification emails.
I thought internal comments were only for agents, how is it that non-agents are getting emails when one is added by an agent?
In my case our users all have full jira software licenses, but access our servicedesks through the portal view, is the fact that they have jira software licenses somehow giving them extra visbility? In the case that I'm investigating the user was on the issue as an approver, and also in the request participants list. Is there some specific settings I need to have in place in either project permissions or notification scheme to prevent non-agents from getting email notifications when internal comments are added by agents?
If you have any collaborators that have jira software licenses then they will also receive internal comments if they are watching an issue. However customers should never see internal comments.
Thanks Jack. So an agent(or someone with update rights on ticket) would have to explicitly go in and add them as a watcher, and this would be different than being in the Request Participant list, correct? So it sounds like a procedural fix would be to have agents not add people to watchers list that they don't want to see internal comments?
Regards,
Jay
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Well if you give browse permission to any internal licensed users then they could easily go in and find tickets and set themselves as a watcher as well. It all comes down to how you have permissions set in conjunction with notifications.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, I already have browse turned off except for servicedesk agent role, which creates another problem with populating user pick fields. It's tough to be aqble to truly mask these internal comments to just agents it seems without restricting other rights as well. Thanks for the help on this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes but keep in mind if you give someone browse permissions then they will see all the comments regardless of whether they receive the notification of the comment. So the bottom line is if you don’t want someone to be able to see the comments then don’t give them browse issue permissions. You can’t separate and hide comments from the actual issue detail view.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Jack Brickey - If I set someone as a "request participant" is it true that they cannot see or read internal comments?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Correct - assuming that they are a Customer and not licensed to access the application. In some JSM projects customers our internal and may be licensed within the year application. Further they may have browse access to that project in which case they could see internal comments. However, I suspect in your case this is external customers were talking about.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for the prompt reply @Jack Brickey
Yes, in this case it's a customer that we want to see updates - but not view our internal discussion. If we want her to see updates (she wasn't the reporter, I was) then giving her "request participant" access would simply allow her to see anything we write into the 'Reply To Customer' field, correct?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Correct. They will also be able to find in the portal if they search under the request button.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.