I would like to keep the original email sender address in JIRA, when I receive an email, which is handled by JIRA. Currently JIRA replaces the sender with the JIRA Master Admin address. I remember, that we had setup the handler to keep the original email address on another company I administerd JIRA, but don't remember how we managed to do this.
Reason why I want that is, that I would like that the sender is being informed automatically on the updates (adding comments, status changes etc.) wheneverr that is done.
The JIRA is handling issues very easily.. The reson why JIRA is replacing the sender email as a JIRA Master Asmin is probably becouse you have set up a default reporter (reporterusername property) in your handler and user is not recognized.
When JIRA do not recognize the user and it is automaticaly setting up the user specified in reporterusername. If you want to inform senders about every change they need to have a valid accounts in JIRA. You can eather create them or set up a createusers property to True. JIRA will then automaticaly create an account for the sender. This will allow the creator to be notified of subsequent updates to the issue, by configuring the notification scheme to notify the 'Reporter'.
If you will specify notifyusers next to the creteusers then all senders that do not have the account will recive a notification that the account have been created for them.
I hope that helps!
Any more questions.. Please let me know.
Every new user (if it will have jira-users permission) will count to your licence... That means that you can have unlimited number of users but those that can login and use jira must have jira-users permission. Once they are created and the issue issue is resolved you can consider disabling the user to not count to your license.
Okay, thanks Mirek. As I just want to use the notification feature of JIRA to communicate with my customers and they don't require a JIRA login, an automated creation WITHOUT the jira-users permission is fine. Now I remember, that we did exactly this on the other customers installation. Thanks again.
Related, JEMH does the user creation thing in response to new email addresses not associated with an existing JIRA user, but _doesnt_ automatically eat a seat, and can autojoin to a different group. This is all part of JEMH support for large numbers of remote users that dont need to login to JIRA interactively.
Hmm, seems that JIRA sends e-mails only, if the user is in the jira-users group. As soon as I remove the user from that group, I don't receive any emails from JIRA anymore (such as from adding a comment, changing the status etc.). Sounds strange, as I can't imagine that atlassian forces every email recipient to be a licensed user in JIRA as those users NEVER use JIRA.
It does, sort of, but it's not as simple as that.
The logic is not "has to be a jira user", it's actually "the user I am emailing should have permissions to see the issues". Whether that makes them a jira-user or not is a bit different.
This is very much in line with standard security practice - if something is hidden from a user, then they absolutely should not be able to get emails that leak the information to them.
Well, yes, the default mail handler+JIRA won't help you here. By JEMH+JIRA, it has non-jira user support such that they _can_ receive notifications, their email addresses are stored in a custom field and an integrated issue listener renders either default or custom template content for them. Security is addressed as non-jira users are only added at creation time, or when someone in the lists mails JIRA and adds more.
We're looking for participants for a workshop at Atlassian! We need Jira admins who have interesting custom workflows, issue views, or boards. Think you have a story to sha...
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