How should I handle inactive staff in Jira?

Mark McD

I have a Jira (+GreenHopper) instance connected to our staff LDAP directory and am wondering what the "best practice" is for handling staff that leave the organisation (and thus leave LDAP).

I've got a support ticket open regarding a stack trace that GreenHopper is spewing on to some pages when the requestor is no longer in the directory and the suggestion is to migrate all the affected issues to someone else, but I'm reluctant to do this as the data no longer becomes accurate.

In order to keep the data consistent, I could create the users in Jira's internal directory and deactivate them, but this seems to be a manual process.

I don't mind if the inactive user is displayed as a simple username with no links, as it is still clear that 'user.x' requested / changed / touched the issue.

How should I handle users when staff leave?

Manse Wolken

You got a very soft spot there.

We have had the same issue and decided to move the users in the ldap tree.

Active Users are in: ou=active,ou=users,dc=foo,dc=bar

Inactive users are moved to ou=inactive,ou=users,dc=foo,dc=bar

Jira does search the user tree from ou=users,dc=foo,dc=barthis means that jira stell sees all users in the directory.

Inactive users are removed from the jira-users group and can not log in. Thus they don't count towards licences user limit.

And we rename inactive users: "John Doe" becomes "John Doe (inactive)" and the emailadress is set to an catchall address, so jira does not get an invalid adress response if it has to email the author of an old ticket.

Doing this all in LDAP means that a single little script can deactivate users:

1. Remove user from every group in ou=groups,dc=foo,dc=bar

2. Rename user CN, attach "(inactive)"

3. Move user DN in LDAP Tree

4. Store former group information in username.backup in case somebody needs to know quickly

This works best if your lgin usernames are not based on the Name of the user but on employee number!