Important Update Effective February 1, 2024!
Due to recent changes in Jira and Confluence, we've made the tough decision to discontinue the OpenID Connect (OIDC)/OAuth app and no longer provide new versions for the newest Jira/Confluence releases as of January 31, 2024.
This is due to some necessary components no longer shipping with Jira/Confluence, which would require some extensive rewrites of the OIDC App.
Important Update! This app will be discontinued soon!
Due to recent changes in Jira, which no longer ships with some components required for our Read Receipts app to run, we've made the tough decision to discontinue the app, as of Februar 5, 2025.
Important Update! This app will be discontinued soon!
We've made the tough business decision to discontinue the app, as of January 11, 2025.
Administrator Guide
Where To Find
Jira
Navigate to the User Management section and click on User Deactivator:
Confluence
In the administration section, scroll down to USERS & SECURITY and click on User Deactivator:
Bitbucket
Click on the Admin cogwheel icon in the upper right corner and select User Deactivator from either the Accounts section in the left panel or the overview page itself:
Bulk User Operations
Filtering Users
Change multiple filter settings (1) to retrieve users (3) you want to deactivate, reactivate or remove from groups.
These filters are:
- Time Since Last Activity
- Use Last Login As Last Activity (Jira only, please read the paragraph below Cached Results)
- Activity Status
- In Group
- Not In Group
- Application Access
- Directory
- Search in Full Name, Username and Email
Improved User Search (Experimental)
In version 5.2.0 we added a new option to the Misc Settings tab that allows you to enable an improved search algorithm. It is only useful if your Atlassian instance has more than one user directory.
The search results might differ from searching without it enabled, thus the experimental flag. Please compare a few requests with the option enabled and disabled. The option does not affect the search in the Auto Deactivation and License Optimizer feature.
Cached Results
With version 4.3.0 we've introduced a select box to disable the result cache (2) if required. If you are working in an instance with frequent changes to user records, you might want to disable the cache. For example, a user gets removed from a group while you are filtering for users in that group. Only with the cache disabled, the user would disappear from the result list, when running the filter again. If the result cache is enabled and a user has been deleted or renamed in the meantime, you'll see a text instead of the username:
Bulk User Operations Result Cache Default Setting
Since version 5.1.0 you can define whether the cache should always be disabled by default instead. Navigate to the Misc Settings tab and change the corresponding setting:
You need to reload the page after saving the setting to see the change in the Bulk User Operations tab.
Use Last Login As Last Activity
This is available in Jira only. If you are using Jira as a user server in Confluence or Bitbucket and a user logs in to Confluence or Bitbucket, the last activity is also updated in Jira and thus not really correct/ usable. The example shows a user who recently logged in to Confluence but in Jira, he really wasn't active since December last year. In an upcoming version, we'll also add that to the auto-deactivate functionality.
Directory Mode
Since version 4.2.0 you will also see a color assigned to the directory the user is located in.
If it's red, the directory is in read-only mode and you won't be able to deactivate these users.
Usually only removing users from groups will still work then, but only, if the group is not already assigned to the user in the directory.
An example would be a Microsoft Active Directory in Read Only, with Local Groups mode which you've configured so that a group is assigned to the user on the first login. That group could then be removed from the user.
The below screenshot depicts a Microsoft Active Directory in that mode where the jira-software-users group is assigned locally to the users if they first log in:
Per-User Actions
Also since version 4.2.0, you can now
- Edit
- Disable/ Deactivate
- Delete
users from the actions column in the result list on the Bulk User Operations results:
When setting the filter for a specific directory, (1) is not available. This is because a user profile is only shown for the user in the primary directory.
One could accidentally modify the wrong user.
For bulk operations, proceed as described below.
Select Users to be Modified
Click the checkboxes of the users you want to bulk operate on and click on Choose Bulk Action
You can also use the Select All button to select all the users matching your filter criteria.
Choose Bulk Operation
Pick one of the bulk user operation types and click on Next
Since version 4.1.0 you may now override the default protection to not deactivate/ remove from groups if
- the user is a component- or project lead of a project in Jira
- the user is a space admin in Confluence
- the user is a repository- or project admin in Bitbucket
Just check the box "Force destructive operations" before performing the bulk action.
Confirm your Choice
Confirm your selection, you'll see a summary of the operation to be executed:
Wait for the operation to complete
Reviewing the Result
The result screen will show a summary of the operation again.
Unsuccessful Login Attempts
Version 4.2.0 introduces new functionality which allows you to see inactive users who have tried to log in again. This will allow admins to get a better overview of whom they might want to reactivate again. The tab contains all the functionality from the Bulk User Operations tab, you can refine the filter, and perform single user actions or bulk operations in the same way.
Automatic User Deactivation
User Deactivator can be configured to automatically deactivate users or remove them from groups instead.
To schedule automatic deactivation, click on the "Automatic User Deactivation" tab and use the scheduler component:
Please be aware that the schedule is saved in the time zone of the server
Jira is running on. Next run shows the converted value already in the time zone of your user profile.
User Deactivator before version 4.9 started automatic user deactivation 30 seconds after the app was enabled and of course, provided that deactivation was enabled.
After that, it ran every 24 hours.
Configure automatic deactivation
Configure a rule that instructs User Deactivator to automatically deactivate users not active for a period of time, for example, 1 year.
User Deactivator will then check for active users every 24 hours. If the last activity date of a user is one year old or more, the user will be deactivated.
Since version 2.1.x (Jira 7) and 3.1.x (Jira 8), the following changes and features have been introduced:
- Email Address for receiving a report about the users modified during auto-deactivation has become optional
- if none was provided, no summary report will be emailed
- if none was provided, no summary report will be emailed
- if User Deactivation Mode has been set to "Remove Users from Groups" and one or more group names have been selected,
users will be removed from these groups instead of being deactivated- this feature is specifically intended for users who manage users of i.e. Confluence via their Jira directory
- you could remove users from all groups starting with "jira" and "confluence" and would revoke their access for both Atlassian platforms that way
- this would then also save Confluence licenses
- please be aware of this being a specific setup of Jira/ Confluence with Crowd, it does not automatically apply to all Jira and Confluence installations
- select one or more group names whose members would be excluded from deactivation or group removal
- exclude groups overrules the "Groups to remove", should you (accidentally) provide the same group names in both
A user cannot be automatically deactivated or removed if:
- the user is a system administrator or administrator
Since version 4.1.0 you may now override the default protection to not deactivate/ remove from groups if
- the user is a component- or project lead of a project in Jira
- the user is a space admin in Confluence
- the user is a repository- or project admin in Bitbucket
Just check the box "Force destructive operations" before the Reporting section in the automatic deactivation
Remove autoGroupsAddedAttribute
Please read more about this feature in our knowledge base.
Expiration email to users
If you select an option other than "Don't send Email" under the "Days before sending expiration email to users" option,
users will receive a notification from 1-14 days prior to deactivation or group removal and can prevent deactivation/ being removed from groups by logging in again.
When activating this option for the first time, users who are already inactive for longer than the period selected in the Time since Last Activity picklist won't receive an expiration warning email.
They will be deactivated or removed from groups as soon as the next daily auto-deactivation job runs.
The emails look like the below:
Warning about being removed from groups
Warning about being deactivated
Email report of automatically deactivated users
If one or more users are automatically deactivated or removed from groups, a report will be sent to the recipients added in the reporting section:
The summary email looks as follows:
In case some users couldn't be deactivated because of an unexpected error, a second table in the report will indicate this.
If nobody was deactivated or removed from groups, no mail will be sent.
Microsoft Active Directory
User Deactivator for Jira works as follows with different configurations of Microsoft Active Directory.
Jira configuration | Function |
---|---|
Read Only | If an attempt to deactivate a user in a read-only Active Directory, an error message Cannot edit user, as the user's directory is read-only will appear. The user cannot be deactivated. |
Read Only with Local Groups | If an attempt to deactivate a user in a read-only Active Directory, an error message Cannot edit user, as the user's directory is read-only will appear. The user cannot be deactivated. |
Read/Write | A user residing in a read/write Active Directory can be deactivated |