Description

Personal Data (PD) for a specific user can be spread across multiple components of Jira. We've detailed these components and areas in the Jira: Right of access by the data subject article. In this article, we'll describe how to remove personal data for a specific user, if required. Depending on your Jira version, you can either do it directly from Jira or use workarounds, that is run SQL scripts on your database. We strongly recommend you stop Jira to run these scripts, which will result in downtime for your Jira instance.

Version Compatibility

• Anonymizing users directly in Jira (recommended)
  Jira Core and Jira Software 8.7 and later, and Jira Service Desk 4.7 and later.
  
  
• Using workarounds and running SQL scripts on your database
  Jira Core and Jira Software 7.0 and later, and Jira Service Desk 3.0 and later. 
  Some SQL statements are only available for certain products or versions, e.g. Jira Software or Jira Service Desk 3.5 onwards. These limitations are documented in comments inside the SQL scripts, before each table. 

Removing personal data

Anonymizing users in Jira

Anonymizing users in Jira allows you to hide or delete any data that can identify them as a real person. This includes names, usernames, avatars, personal settings, and any occurrences of those around Jira. For more info on what the user anonymization looks like and what exactly gets anonymized, see Anonymizing users.

Using workarounds and running SQL scripts on your database

Overview

This section contains a high-level overview of the process required to remove personal data from a Jira instance. Specific instructions on how to remove personal data from a Jira instance are covered in the next section.

Deleting or modifying PD

Deleting and modifying user PD is virtually the same process. This is because we don't recommend fully deleting a user account from Jira. User accounts are an integral part of the Jira data structure and critical for maintaining data consistency on your system.

Rather than deleting the data, we recommend modifying PD elements in the account to replace PD with data elements that do not identify the user. For example, replacing the username "johnsmith" with "deleteduser1".  This way the system will be able to function correctly while allowing you to "delete" profile-level PD that may otherwise identify the user. You can also use this process if you want to modify a user's PD - for example, if "nicholassmith" is known as "nicksmith." 

Modifying user PD - high-level overview

Modifying user PD has to be performed in several steps, depending on where the data is stored. Some PD can be modified through the user interface (UI), while other PD has to be modified directly in the database (SQL). We recommend using the UI where possible to avoid the risk of unintentional data modification or deletion. Making changes from within the UI ensures that the Lucene index and Jira caches are updated.

To modify the user data you have perform the following steps (detailed steps are described in the next section):

1. Changes you can make in the UI:
   1. Handling PD in "structured" data fields
      1. Modify data in the user profile. This depends on the type of user directory Jira is using:
         1. If Jira is using the internal directory, please read Managing your user profile for information on how to do modify the user profile.
         2. If Jira is using an external user directory, you will need to follow the instructions for the external user directory to update the profile, and then Synchronizing the data with Jira. 
      2. Remove a user's avatar in their user profile
   2. Handling PD in "free-form text" data fields that are JQL searchable (issue-related)
2. Changes that require SQL update statements (SQL update statements must be executed against a Jira instance which has been stopped):
   1. Optional modification of "user_key" - only if "user_key" contains PD.
   2. Handle PD in "free-form text" data fields that are not JQL searchable (non issue-related)
3. After change actions (only if SQL update statements were executed) 
   
   1. Reindex Jira

Process to remove personal data from a Jira instance

Step 1 - (UI) Handling PD in "structured" data fields in the user profile

This step depends on the configuration of Jira. You can manage users within Jira  by using "Internal user directory" or user management can be performed in an "External user directory". More information on user directories can be found on this page: Configuring user directories.

The procedure for modifying personal data depends on which kind of directory Jira uses for a specific user.

You must have the Jira Administrator or Jira System Administrator global permission to be able to manage users in Jira applications. To find out which kind of directory is used for specific user perform following steps:

1. Select  > User Management.
2. Find the user in the user list using the filter form at the top of the page.
3. Check the Directory column in the table, it will contain the directory used to manage the user. This should tell you whether you're using an internal or external user management system.
4. Click on the user's Full name in the "Full name" column. Take a note of the following details for later use:
   
   1. Username
   2. Full name
   3. Email

5. Obtain the user_key for the specific user and check if it contains PD. You have to use the username obtained from the user profile in the previous step.

   On Windows, you should have CURL installed, use this or find another way to call the REST API or use the SQL query.

   
   

   1. Using Jira's REST API to obtain the "key" value from the response:

      curl -u admin:admin http://localhost:2990/Jira/rest/api/latest/user?username=example_username
      {
      "self":"http://localhost:2990/Jira/rest/api/2/user?username=example_username",
      "key":"user_key",
      "name":"example_username",
      "emailAddress":"johndoe@example.com",
      "avatarUrls":{"48x48":"","16x16":""},
      "displayName":"John Doe",
      "active":true,
      "timeZone":"Australia/Sydney",
      "locale":"en_AU",
      "groups":{"size":2,"items":[]},
      "applicationRoles":{"size":2,"items":[]},
      "expand":"groups,applicationRoles"
      }
      
      
      In this example user key has value "user_key"

   2. Using a SQL query (replace [username] with the user name we are looking for)

      select user_key from app_user where lower_user_name = LOWER('[username]')

Once you have determined the type of directory and you have obtained the PD from the user profile, you can proceed with the next steps.

External user directory

These steps should be performed if your Jira instance uses an external user directory.

There are 2 options that you can take to remove a user's PD, either modify the details to something anonymous, or delete the user completely:

1. Modify the user's PD in the external directory:
   1. Modify the user's PD and disable their user account in the external directory.
   2. Synchronize the external directory with Jira.
2. Delete the user's PD from an external directory
   
   1. Follow the steps from Modify the user's PD in the external directory above. Right now user data in Jira should be updated (synchronised) with the data from external directory, and user account should be inactive.
   2. Find and delete the user from the external directory.
   3. Synchronize the external directory with Jira.
   4. At this point 2 things can happen:
      1. If the user has not created any issues, and they're not the reporter, creator or assignee of any issues, then they will be deleted and removed from the user list.
      2. If the user has at least one comment or there is at least one issue that user is reporter/creator/assignee, then the user will be deactivated.

External user directory with delegated authentication

These steps should be performed if the user resides with an external user directory with delegated authentication.

1. Disable or delete the user in the external directory.
2. Follow the steps from Internal user directory below.

Internal user directory

These steps should be performed if the user resides within an internal user directory.

Remove user avatar

Jira allows users to upload avatars (to be used in profile page and displayed on view issue page). An avatar may contain PD (eg. user photo).

Step 2 - (UI) Handling PD in "free-form text" data fields that are JQL searchable (issue-related)

Personal data can be stored in Jira issues or entities associated with issues e.g. comments, worklogs etc. Jira allows free-text searching (using JQL - Jira Query Language see: Searching for issues ) in issues and entities associated with issues (issue fields, comments, worklogs, text-searchable custom fields).

JQL searching can be used to search for PD stored in issues. We'll use the "text" field to perform searching as it searches through Summary, Description, Environment, Comments, Worklogs, and custom fields that use "free text searcher". Read more on Advanced searching. If personal data on your instance is stored in fields that are not handled by a "text" field, then you need to alter the JQL query to search in those additional fields.

1. To go to the issue search and search for sensitive data, choose Issues > Search for issues.
2. Click Advanced.
3. Enter your JQL: "text ~ 'clause to search'" and click search. This will search in: comments, description, summary, environment, worklogs + text searchable custom fields.
4. Individually modify all comments/summary/description/issue fields/worklogs/custom fields returned in your results.

Step 3 - (SQL) Changes that require SQL update statements (these are not possible in the UI):

This step consists of several sub-steps:

• Stop you Jira instance - to avoid mismatch (data loss/inconsistencies/corruption) between DB and caches used by Jira 

• (Optional) Modifying user_key - perform only when user_key contains PD.

• Handle PD "free-form text" data fields that are not JQL searchable - deals with free text data stored in entities that are non JQL searchable.

• Start the Jira instance  - this will ensure that the database modified values are properly loaded into Jira caches

Stop your Jira instance

This step is required because Jira caches a lot of data and updating the database directly when Jira is still working could cause data loss, inconsistencies or corruption.

See: Start and Stop Jira applications.

Modifying user_key - (Optional - only when user_key is PD) 

Jira uses the user_key (database table app_user column user_key) internally as a foreign key in other entities eg. Jira issue, issue comment, default assignee etc.

A user_key may contain personal data (e.g. the user key could contain the first and last name of a user).

Because the user_key is immutable in Jira, and changing the username for a Jira user will not change it's user_key, SQL queries have to be performed to change the user_key that is used as foreign key in other database entities.

Handle PD "free-form text" data fields that are not JQL searchable

Only data associated with issues can be searched for in Jira using JQL queries, but personal data could also be stored in other entities within Jira (eg. statuses, resolutions, schemes, workflows, screens, archived projects, etc.). In order to search all potential places that personal data could be stored, you need to run a SQL query against the database.

Start your Jira instance

Start the Jira instance - this will ensure that the database modified values are properly loaded into the caches.

See: Start and Stop Jira applications

Step 4 - Follow up actions (only if SQL update statements were executed)

Jira stores certain data in a Lucene inverted-index to make JQL searching possible, so if the SQL update statements were executed you now need to re-index Jira in order to remove stale data from the index.

Scripts to query and/or update project and component lead

A user can be assigned as a project or component lead, and as such you may need to find and/or update these details. User account can't be deactivated if the user is a project or component lead.

The following scripts can be used to query and update the project and component leads in Jira so user account can be safely deactivated.

Python3 script used for querying/updating leads of projects.

> python3 project_lead.py -u admin -p admin -m select --url http://localhost:2990/Jira --old old_admin_username --new new_admin_username

> python3 project_lead.py -u admin -p admin -m update --url http://localhost:2990/Jira --old old_admin_username --new new_admin_username

Python3 script used for querying/updating leads of components

> python3 component_lead.py -u admin -p admin -m select --url http://localhost:2990/Jira --old old_admin_username --new new_admin_username

> python3 component_lead.py -u admin -p admin -m update --url http://localhost:2990/Jira --old old_admin_username --new new_admin_username

Limitations

General Limitations

• SQL statements are using pattern matching, so they may match records that don't need to be modified. Manual inspection is suggested before each update to ensure you don't modify records that don't need to be modified.

• The History tab might contain sensitive data - it can be erased via an SQL query, or by cloning the existing issue, and then deleting the existing issue completely.
• If "Modifying user_key" was performed be sure to also follow "Handling PD in other entries" step.
  Altered user key could be used in eg. workflow post-function (eg. set assignee in post-function) or as custom-field default value (eg. default "manager" in user picker custom fields).
  SQL queries from "Handling PD in other entries" step can help you identify those places and update them accordingly.

JQL Limitations

Jira allows searching by various fields eg. status, priority, resolution, issue type, saved filter, component, version, custom field name, labels etc.  (Advanced searching - fields reference). All these entities can be referenced in a JQL search which is saved as a filter, and changes to those entities could break existing saved filters:

• filters (Saving your search as a filter)
• filter subscriptions (Working with search results)
• gadgets that use JQL filters of JQL (Adding and customizing gadgets)
• reports (Reporting)
• boards (Configuring filters)
• board swimlanes (Configuring swimlanes)
• board quick-filters (Configuring Quick Filters)
• possibly other places that rely on saved filters or free-text JQL queries

If you're running Jira Service Desk, then JQL filters can be used in following places:

• Queues (Setting up queues for your team)
• Reports (Setting up service project reports)
• Automation (Automating your service project)
• SLAs (Setting up SLAs)

Database Specific Limitations

• Mysql doesn't have a "REGEXP_REPLACE" function (or any other functions that would work in similar manner), so we're able to find matching records ignoring case, but we're not able to generate sql that will update values in a case-insensitive way. Manual inspection/update is needed in these cases.
• Microsoft SQL Server does not support regular expressions to the extent of other supported databases - records are matched using "LIKE" operator which can match longer substrings. Updates are using a "replace" function which, in conjunction with case insensitive collation, will replace all occurrences case-insensitive to case-sensitive replacement eg. replace("and TEST second as test third", "test", "tESt") = "and tESt second as tESt third". 

App Specific Limitations

Jira Service Management

• Insight - Asset Management is an app bundled with Jira Service Management Data Center 4.15 and later. It’s also available for earlier Data Center versions. In some cases, when you anonymize users, their user keys won’t be anonymized in Insight - Asset Management. This affects user keys of users created before Jira Service Management 4.7 (or Jira 8.7). In these versions, user keys look the same as usernames, so some personal data might be visible. Users created in later versions will be fully anonymized, also in Insight - Asset Management. The reason for this difference is that later versions use a different pattern for usernames and user keys, and in this case we’re only able to anonymize the new pattern.

Additional notes

If you are a server or data center customer, Atlassian does not access, store, or otherwise process the personal data you choose to store within the products. For information about personal data Atlassian processes, see our Privacy Policy.