We recently tried to move our Jira 4.4.1 instance from one user directory (OpenLDAP) to another (Novell eDirectory).
The OpenLDAP system is our internal LDAP, and email addresses in here have suffixes: @nihi.auckland.ac.nz
The University eDirectory which we wan to move to, has suffixes: @auckland.ac.nz, and sometimes @aucklanduni.ac.nz
Each of our users have their email client still sending emails with suffix: @nihi.auckland.ac.nz, and this mismatch results in Jira not picking up mails which are sent to a group inbox, where the Jira IMAP mail server is configured to process them.
My thoughts were to set the eDirectory synchronisation to run daily (it is hourly at present), and after it runs, have a SQL update on the CWD_USER.EMAIL_ADDRESS, CWD_USER.LOWER_EMAIL_ADDRESS fields to force the email address suffix to: @nihi.auckland.ac.nz.
However, after doing this, Jira still doesn't pick up existing (or new) emails in the group mailbox. When I go into the User Administration, I see the users still have the suffix: @auckland.ac.nz, instead of: @nihi.auckland.ac.nz. So maybe there is caching somewhere? I could bounce Jira, but I really don't want to do this.
Is there a way to force Jira to re-read the database table?
If there is a better way to do this, I'm open for suggestions.
BTW, we can not change the University email address suffix, nor does the business want to remove the @nihi part of their email on the mail client.
I'm aware Jira doesn't handle multiple emails,... but how are we supposed to get around this?
Thanks in advance,
After some discussion with Atlassian (JSP-145251), the options were:
1. Internal Directory with LDAP authentication
2. Add a new emai property in eDirectory and use this when populating the email address in Jira
Option 1 is not good for us, as we want group synchronisation.
Option 2 is a possibility.
Atlassian confirmed that Tomcat will cache the embedded Crowd tables and will require a restart to update them in certain situations. I tested a variety of possibilities and came to this conclusion as well. I found that the emails sitting in the group inbox were picked up and processed, but then the directory sync kicked in immediately afterwards and set all the email addresses back again. Not an ideal solution,.... I'll be raising a feature request on this.
Stuart, thanks for updating your question with the answer - we really appreciate it! :)
One other option was to restrict the SMTP so that it enforces the sender email to be what is in the eDirectory for that user. This way no matter what sender email is in the email client, it would still send as the email address that matches the mail attribute for that user, so JIRA will correctly match the user.
Just to chime in here, coming in JEMH 1.3 is the start of a pluggable API that will in that release allow users to provide 'translations' from incoming email address to 'internal' email address. This could be as simple as making an address firstname.lastname@example.org to email@example.com and is how JEMH LDAP support manages users of Exchange with the variety of M$ products that use some of users proxyAddresses (Active Directory attribute) for different emails that are associated with a common user.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
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