The two different things people mean by "comment permissions"
These get mixed up constantly, and they are configured in completely different places.
1. Who can add, edit or delete comments. This is the permission scheme, set per project.
2. Who can see a comment once it exists. This is comment-level visibility, set per comment by whoever writes it.
If your problem is "the wrong people are reading our comments", it is the second one you need.
Comment permissions in the permission scheme
Go to Project settings, then Permissions. The comment permissions are:
- Add Comments. Who can comment at all.
- Edit All Comments and Edit Own Comments. Who can change comments after the fact.
- Delete All Comments and Delete Own Comments. Who can remove them.
Worth reviewing periodically. Default schemes tend to grant Edit All and Delete All more widely than teams realize, which means someone can quietly change what a colleague said.
Comment visibility: the padlock
When you write a comment, there is a visibility control next to the comment box, usually shown as a padlock. It lets you restrict that comment to a project role or a group.
Pick one, and only members of that role or group can see the comment. Everyone else, including the reporter on a service project, sees nothing.
This is the mechanism that protects sensitive comments. It works well.
Its weakness is that it is entirely manual and it fails open. The default is "viewable by all users". Every comment starts unrestricted, and the person writing it has to remember, every single time, to change it. On Jira Service Management the internal and customer tabs help, but everywhere else you are relying on habit.
One missed click is a disclosure.
What you can do natively
Review your permission scheme. Free, quick, and worth doing regardless.
Use Jira Service Management's internal comment tab where it applies. On a service project, the internal note tab is a genuine separation and it is clearly labeled.
Train the team and hope. This is the honest description of what most teams actually rely on, and it is why the problem keeps recurring.
Restrict the whole work item instead. If the entire work item is sensitive, an issue security scheme is a stronger control than per-comment restrictions, because it is applied by configuration rather than by the person typing. It is a blunt instrument, but if the answer is "nobody outside this group should see any of this", it is the right one.
Changing the default instead
The underlying issue is that the default is wrong for your context. Fixing the default, rather than correcting each comment, removes the human step.
Full disclosure: I work for Redmoon Software, and Comment Security Default is our app. The sections above stand on their own whether or not you use it.
Comment Security Default lets an administrator decide what new comments default to, instead of leaving every comment viewable by all users. You set the default globally or per project, and target it by group, so different teams can have different defaults in the same instance.
It also colors the comment field according to the restriction in force, so the person writing can see at a glance whether they are about to post something publicly.
Cloud works differently than Data Center, and there are two constraints worth knowing before you evaluate it:
- It requires a companion Google Chrome extension, installed on every browser that should pick up the defaults. The Forge app handles configuration, but Forge is not permitted to restyle or pre-fill the native comment editor, so the extension is what applies the default and the coloring in the browser. Without it, comments fall back to standard Jira behavior.
- Jira Cloud has fewer comment fields than Data Center. There are no comment fields on attachments, work logs, work item links, edits or bulk edits. There are comment fields on transitions, and you can set a default for those.
I would rather you know both of those up front than discover them mid-trial. There is a free trial on the Marketplace.
Which control fits which problem
Problem | Control |
|---|
Wrong people can edit or delete comments | Permission scheme |
One specific comment is sensitive | The padlock, per comment |
Whole work item is sensitive | Issue security scheme |
Comments keep getting posted publicly by accident | Change the default |
Customer-facing service project | JSM internal comment tab |
If you have solved the "default is wrong" problem another way, in automation, through a workflow validator, or by process, I would genuinely like to hear how. It is a gap a lot of teams work around differently.
