We are using Jira with MS-AD Synchronisation to our corporate AD (LDAP). The in the mail attribute noted mail address is currently always used to be the one where notifications are sent.
Now we have a certain constellation where we need to get this notification sent to a different address of that user.
I could not find a plugin or similar idea to make it possible that either the user itself can change it's mailadress where notifications have to be delivered or how to set up by administration a different mail address.
We can NOT change the mail address field in the corporate Active Directory as there are a lot of other applications linked to that and we would get in troubble with compliance issues.
Do you have an idea? Do you know a plugin that might help?
yes this is not a best idea, and will have some support cost ( you will need to manage two mail fields per user instead of one ) but it's easy realised - for beginning just copy current AD e-mail to this new field, and then change this field only for users who need change. but i hope users won't change jira notifications e-mail often?
Its not clear what scenario determines the address needs to be rewritten. Is it always or when X=Y (if so what)?
Bottom line, if you are OK for userX to receive a copy to the default email address, you need a customized IssueEventListener to do this. The custom IssueListener could then say 'aha' I have userX, and create a new notification for the subsitute address.
If you want to stop the notification to the first address that becomes more complex but is still doable.
Mmmm ... it's a bit crappy but here I go:
-In the LDAP server: define a custom attribute for the affected users and store his secondary email in it. Then define a LDAP group including all ldap-users that should be notified to this secondary email. Let's call this group: [secondary-email-group]
-In Jira, duplicate the directory definition. Both directories are the same ldap-server but in the first one add a "User Object Filter" condition to prevent users belonging to [secondary-email-group] group to login. In the second directory, change the email mapping to use the custom attribute as email.
This way, users in the XX group will login by using the second directory (which is the same server but with different email-attribute mapping).
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot