What can possibly be adversely affected by disabling users in Jira?

[Kobi Rosenstein]

I am 3 users away from reaching my license limit.

Many  (most) users are in a delegated LDAP directory, and are set there as disabled.

At first I tried deleting the disabled users from the Jira DB, as documented here:

https://confluence.atlassian.com/jirakb/how-to-delete-jira-user-from-database-733937809.html

That caused some errors, where for example the Assignee dropdown would not load, and  the recommended SQL produced user IDs which were not correct. So, I rolled back the database change.

Next, I tried simply disabling the users (I only learned this was an option afterwards) as explained here:

https://confluence.atlassian.com/adminjiraserver/create-edit-or-remove-a-user-938847025.html

https://confluence.atlassian.com/jirakb/bulk-disable-jira-users-1063562242.html

This worked well, but then users complained that they were not able to see their dashboards - it turns out that some dashboards and filters were owned by inactive users, so once again I rolled back the change.

Now, I MUST clean my inactive users, but going into this activity for the third time now, I really, really, don't want to have to do another rollback.

My question is this:

What are ALL of the possible negative side effects of deactivating multiple users? What can possibly go wrong and what steps must I take to ensure nothing breaks when I deactivate them next time?

[Elias Brattli Sørensen - Kantega SSO · Accepted solution]

Hi Kobi,

I am not familiar with all possible side effects of deactivating users, but I do know of a possible solution that might be feasible for you.

An alternative to having to deal with the negative side effects of setting as user to inactive can be simply removing them from the group(s) that give licensing to Jira. Say if you configured global access so the group  `jira-software-users` gives access to a Jira Software license, then it's the membership there that adds to the license count, regardless of whether or not the user is "active". Simply removing the user account from this group will ensure that their access is prohibited. This allows you to manage the licensing limit without having to deal with the consequences of deactivation and deletion. This solution might be expanded if your LDAP provides access elsewhere by ensuring that all integrated third party products enforce access control based on groups. Of course if the user is off boarded from the organization I understand the necessity to remove them / deactivate them from AD.

We offer a feature called User Cleanup in our product, Kantega SSO Enterprise, which allows you to automate this process. With User Cleanup, you can schedule an automatic job to run at a desired time interval, and remove users from the desired groups on a scheduled interval, based on the user's last login date. This ensures that users that haven't logged in say the last 3 months, can automatically be removed from the group that consumes licenses. At the same time, using our SSO, the users can be automatically reenabled / re-added to the licensing group during their next SSO login, with Just-in-time user provisioning.

Regards,
Elias
Kantega SSO

[Kobi Rosenstein]

Thanks Elias! That workaround worked perfectly for me.

[Sanjog Sigdel]

Hello @Kobi Rosenstein 

If you remove a user from JIRA, there might be issues with handling the tickets created by those users. Also those tickets will be unassigned and we need to perform bulk operation.

But if you simply deactivate their credentials, meaning no site access and account inactive, it will not create any problem. It will be easy for us to handle users and migrate those tickets assigning it to someone else. Or it can be as is only.

Also license won't exceed when users are suspended or deactivated.

[Kobi Rosenstein]

As I explained in my post, deactivating users DID cause problems. I am trying to prevent any more unexpected behavior.