Email address suffix headache for Jira after user directory change...

[stuartu]

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,

Stuart.

[stuartu · Accepted solution]

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.

[Dave C]

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.

[stuartu]

Thanks for highlighting that.

It would be true if our eDirectory was integrated with our mail server (Exchange), but it isn't for us.

[Andy Brook [Plugin People]]

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 user@abc.your.co.net to user@your.co.net 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.