Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Excerpt

To save on licensing costs, it is sometimes useful to automatically deactivate Jira users who haven't logged in within a certain period, say 6 months. Here we review the options, and provide a ScriptRunner script that does the job.


Table of Contents

Which users can we deactivate?

First, it's worth thinking through the rules for which users you want to be automatically deactivated:

  1. "User has not logged in in X months" is a good start.
  2. How about users that have never logged in? It depends on the age of their user account: if it was created yesterday, but they haven't logged in yet, that's fine; if it was created last year and they haven't logged in, it should be deactivated. So let's also deactivate users whose account was created more than X months ago, AND who have never logged in.

    Note
    iconfalse

    Incidentally, if you do a web search for Jira deactivate inactive users' you will see many solutions, like this ScriptRunner script from Adaptavist, that don't handle this edge case (probably because Jira's regular API doesn't expose the 'created' date).


  3. Jira instances often have multiple directories. It's not possible to deactivate users in LDAP / AD User Directories, so let's add the criteria: users are in the internal (id 1) or Crowd directory (e.g. id 10000)
  4. Does your Jira have an 'admin' role account on the Internal directory, only used in emergencies when the external user provider (Crowd, LDAP, external Jira) is offline? This shouldn't be automatically deactivated. We must add the rule exclude emergency access accounts.
  5. Does your Jira contain any 'role' accounts never log in, but are still valid? Perhaps a role account like 'qa' that is assigned issues so that qa@mycompany.com gets notified? If so, we need a exclude role accounts that are used but never log in rule to prevent these role accounts getting deactivated.

Generic ScriptRunner Solution

Our first generic solution is a ScriptRunner for Jira Groovy script. It deactivates users matching rules 1, 2 and 3, namely users in the Internal Directory (1) who have not logged in X months, or who have never logged in to an account created more than X months ago.

...

  • Save the above script to $JIRAHOME/scripts/deactivate_inactive_users.groovy. Make it owned by root but readable by group jira.
  • Go to the Scriptrunner Script Console and do a test run:
  • If all looks good, go to Jira's Services  admin page, and add a service of type com.onresolve.jira.groovy.GroovyService 

ScriptRunner Solution with SQL Rules

How about if your rules for who to deactivate need to be more sophisticated than just 'user hasn't logged in in 6 months'?

...

The script should be installed in $JIRAHOME/scripts/deactivate_inactive_users.groovy and invoked automatically as a service, as described above.


Other options

Before writing the ScriptRunner Groovy scripts above, I considered (and discarded) a few other options.

Plugins

As of , the only relevant plugin is Manage Inactive Users. This free plugin also supports deactivating users in external user bases like Okta and Google Apps.

I am waiting on feedback from the author before passing judgement.

REST Script

Without any plugins, the cleanest solution would be a script utilitizing Jira's REST interface. The script would search for inactive users with Crowd CQL, then deactivate them. A REST solution would have the advantage of also working on Cloud Jira.

...

Given the potential slowness, and lack of REST support, I didn't pursue this route too far.

Direct database hackery

We have SQL identifying exactly what accounts we want to deactivate. Couldn't we just change the SELECT to an UPDATE that sets active=0 , and do the deactivation directly in the database?

...

I haven't researched this much further, as instances I work with all have ScriptRunner available.

Conclusion

Using ScriptRunner, we have implemented a means for Jira to automatically deactivate inactive users, thus saving license slots. This is (to my knowledge, as of  ) the only implementation that handles never-logged-in users. Users who require more flexibility can use the SQL-augmented approach.