Disable accounts / set invalid email address

[Andrei [errno]]

as mantioned in "Practical JIRA administration" book / section 6.4:

Once a user leaves an organization, their email address will eventually become invalid and may cause "bounce" errors in the JIRA log files. To avoid this, change the top-level domain in the user’s email address from <tt>.org</tt> or<tt>.com</tt> to <tt>.invalid</tt>, which is the official way to mark an email address as invalid (RFC 2606).

when i set email address im my Crowd to user@example.invalid - JIRA is still trying to email those users and i get bounced emails.

has anyone done the same in their environment? does .invalid work?
I can think of another solution of setting their email to noreply@example.com, but I would like to keep their emails mostly intact, just in case they need to be reactivated in the future.

thanks

[Nic Brough -Adaptavist- · Accepted solution]

I've found organisations are very weak on their support for the standard .invalid RFC. Bad, I know, but we live in a world with Internet Explorer to which "standard" is something to be comprehensively ignored.

I cheat and talk to the email administrators whereever I go, asking them for an official "null" email address to use. e.g. at my current client, any email sent to <something>l@devnull.local gets quietly, well, piped to /dev/null and hence goes nowhere.

[MattS]

This is still a problem for headless or service accounts. See https://jira.atlassian.com/browse/JRA-39274for a feature request to ignore .invalid addresses. When I wrote the book I really thought JIRA did!

[Mark Symons]

It looks like JIRA v5,1 will contain a solution to your problem:

https://jira.atlassian.com/browse/JRA-3774?focusedCommentId=286717&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-286717

To quote, this is what we should be getting:

• Inactive users can't log in
• Inactive users don't count toward license limit
• Inactive users don't receive email notifications
• You cannot assign issues to inactive users
  However, you can edit an issue and leave the existing assignee even if inactive.
• Project Leads and Component Leads cannot be deactivated
• Inactive Users are displayed in UI, but with a trailing "(Inactive)" as an indicator.
• JQL searches on inactive users work (eg reporter=jdoe)
• JIRA will respect the active flag from Crowd servers
• JIRA does not have an active flag for LDAP users
  Because only AD has this concept AFAIK, and we are leaving the door open for JRA-24937

Now, this seems to deal very nicely with dealing with some important use cases... although it does not cater for the use of dummy users (such as "test queue").

[Ivan Tse]

This ties in with disabling accounts in JIRA without having to migrage all data away from the, but if you are simply in the process of cleaning up users who have left the company, the simplest thing to do would be to remove them from all user groups.

This way, they won't be able to login and none of workflow process applies to their account. You won't even see invalid email errors in the logs becuase when someone might trigger an event that sends noticifations, one won't be created for the user who is not in any user group.

[Nic Brough -Adaptavist-]

You'll need to check and remove their "roles" too. If a user has "browse" permission because of a role that they're in, they could still get emails, despite being removed from all groups.

[Nic Brough -Adaptavist-]

I've found organisations are very weak on their support for the standard .invalid RFC. Bad, I know, but we live in a world with Internet Explorer to which "standard" is something to be comprehensively ignored.

I cheat and talk to the email administrators whereever I go, asking them for an official "null" email address to use. e.g. at my current client, any email sent to <something>l@devnull.local gets quietly, well, piped to /dev/null and hence goes nowhere.

[MattS]

Me too