How to handle removed Users?

[David Toussaint [Communardo]]

Hi,

I am comming across this every now and than and it is a real PITA (imho)! If a user is deleted in JIRA (or no longer synced from the LDAP) working with jira is a mess. This can occure e.g. if someone leaves a company...

The following scenarios with removed users make me facpalm a lot:

• removing the user form a project role -> exception (ui)
• working with issues where said user is watcher -> exception (log)
• editing shared filters and dashboards from those users -> exception (ui)
• editing an issue where such a suer is author with having the right to modify the author -> can't safe the edit at all!
• This list could go on and on and on...

Fur us we often have to remove users for different reasons and this usually done by removing them from the LDAP. How should we approach above stated problems? Or how would a process look like in order to avoid said problems?

Thanks and Cheers, David

[MatthewC · Accepted solution]

from my experience it is a PITA (never used that acronym before but I like it!), maybe even a RRPITA (a Right, Royal PITA)

First, I presume you've read these:

https://confluence.atlassian.com/display/JIRA/Managing+Users#ManagingUsers-Deactivatingauser

Editing issue after user deleted

https://confluence.atlassian.com/display/JIRAKB/Cannot+Edit+Issue+After+User+Has+Been+Deleted

How do we handle it? We periodically sweep the user database and have a script which checks if they are still in the LDAP server. if not, we remove all groups and add them to a marker group (Dead Accounts) and deactivate them. We also get reports from HR about leavers and the suport team does manual updates to reassign issues which are assigned to the dead account. becomes a bit more complex when they are project lead as well, you have to manually look for that.

The whole way user accounts is handled is a bit of mess but it's getting better in Jira 5.

[David Toussaint [Communardo]]

Yes, I know both ressources. The thing is, deactivating a user is not available when the user has just been excluded from the LDAP sync. So the process would be:

1. "remove" (exclude from sync) user
2. re-create user in internal directory
3. deactivate user (on pre-jira 5.1: remove user from all groups and project roles)

Now one would be save, korrekt?

[Renjith Pillai]

Or isn't it just sufficient that the user is removed from the group which is used in the JIRA Users global permission. Sync can happen, the user will still come from LDAP, but is not active and won't count to license since he can't login.

[David Toussaint [Communardo]]

@Renjith The problem is that the user is just beeing removed from Sync. There is no way for me to avoid this (higher power, say administrators are in charge). If that would not be the case, your proposed solution would be indeed sufficent.

[Renjith Pillai]

Ah ok, can understand. Otherwise you should be using Internal with LDAP authentication (Copy User on Login, Synchronise Group Memberships).

[Dave C]

If a user is deleted from the LDAP engine (typically Active Directory), when JIRA periodically synchronises (if using a connector) that user will be deleted in JIRA. As linked earlier, we recommend to deactivate users rather than deleting them as it can cause a number of problems in JIRA. You could workaround this with any of the following (this is also summarising from some earlier answers):

1. Deactivate the user from the LDAP engine rather than delete them. This will prevent them logging in, however they would also need to be marked as deactivated in JIRA (either removing their groups or using the deactivate functionality). This does rely upon LDAP administrators deactivating rather than deleting.
2. Use the Internal Directory with Delegated Authentication. This unfortunately will not offer periodic synchronisation, however you can copy across users/groups on first login.
3. Add the user to the internal directory after they're deleted from the LDAP directory and remove all their groups. They would need a "dummy" email as well, one that doesn't error or JIRA can end up putting those errors into issues as comments.

[David Luke]

I am having this situation appear, as well. I am in a very large company (60K+ possible users in LDAP) and have no control/influence over the process for removing employees from LDAP.

So #1 won't work.

I use the LDAP diretory to manage my groups because those groups are used in other systems, as well (not just JIRA).

So #2 won't work.

Lastly, I don't know when a user is deleted unless I stumble upon one of his/her tickets and see the grayed user name. So since I don't know when users are deleted from LDAP, I can't do #3.

So #3 won't work.

Is their a #4? At a mininum, I'd like a filter (JQL statement) that flags these orphaned users to my attention. Then maybe I could manually do #3 or otherwise reassign.

[Viktor Nedorezov]

And what is the official decision?