When a user reports a security issue, an email is sent back to them in plain text. All subsequent activity on the issue is also reported by email to all watchers and paticipants.
As it's not really feasible to encrypt such emails, I have been looking for a way to stop notifications for issues that are reported as security issues. Beyond creating a separate project with its own notification scheme, does anyone have a suggestion for how emails could be stopped based on the security level field?
Alternately, is there a way to control what information is sent in emails and controlling that depending on the security level?
You mention the security level field - Jira will only send email to people who can see an issue, so if you're using security levels, that could stop the emails to people who shouldn't see them.
(Unless you've configured something like the JETI plugin which allows you to leak information to users who couldn't normally see it)
Then you need to find out what you have configured that is letting it leak this information and turn it off.
If a user cannot see an issue, Jira will not send email to them, unless you've bypassed the security on emails. It's usually a plugin like JETI or a script-runner function to send extra emails or a post-function to do the same. Or, you might have set up a dummy user with a group email address.
I don't think you read what I wrote, Nic.
Emails are not being sent to people who should not be receiving them. That is not the problem.
The problem is how the emails are being sent. I can find no way of configuring Jira to stop sending emails, or to modify the content of emails, when the issue is a security issue. So the details of security issues are being sent by email, unencrypted and open to interception.
Mmm, it was spectacularly unclear. You've never defined what a "security issue" is for a start. I was assuming you needed to hide them properly from users and had implemented that.
Now I understand that you've got an issue type that you don't want to send email for, but your users should still be able to see it in Jira.
Simple answer - move them to a project with a notification scheme that says "don't send email"
I don't think there's another way to supress email directly without hiding the issues, which means people won't see them in the ui either.
I've never been accused of being "spectacularly unclear" before. We could go around in circles like this for a while, if you like.
We are using a pretty ordinary security scheme with a level field that distinguishes security issues.
I'd prefer not to split our project as it's rather large with many people involved. I had considered that, but it seems there should be alternatives.
You could create a fake smtp server(maybe a relay service) that could scan the email and filter (drop) the email messages before forwarding them on. The smtp relay service could run on the same machine as Jira. The relay service could interface with a secure smtp service if you want to deliver the email securely.
The solution we eventually adopted was to hack the email templates used by Jira. In the templates, there is potential to distinguish security issues and act selectively.
#if ($issue.securityLevel) output a simplified version masking details #else output the normal thing #end
I've reported this issue as a bug to Jira JRA-37581, but Jira doesn't think this is something worth changing. Hopefully they'll change their mind.
It's good to know that we now have a more secure instance of Jira than Jira themselves.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs