JIRA: Right to erasure

Introduction

Under Article 17 of the GDPR, individuals have the right to have personal data erased. This is also known as the ‘right to be forgotten’. The right is not absolute and only applies in certain circumstances. Whether or not you are required to honor an individual's request to have personal data deleted will vary on a case-by-case basis, and is determination you should always make with the assistance of legal counsel. Once you have determined you have an obligation to delete personal data, we have provided the following instructions on how to do so within certain Atlassian products.  

Personal data stored within the product can be divided into one of two areas: 1) account-level personal data; and 2) free-form text. Account-level personal data are data fields that exist within the product for the sole purpose of identifying an individual throughout the product. Examples of account-level personal data include the user's display name, profile picture or avatar and email address. These data elements are generally visible from the user's profile and are used throughout the product to point back to the user's profile when the user is @mentioned or tagged on in certain spaces or content. Deleting account-level personal data elements will automatically remove those data elements throughout the product where the relevant account-level data elements appear and in the database (subject to some limitations discussed below). 

If you have included personal data in free-form text, either typed into content spaces or as a custom field label, you will need to use the product's global search feature to surface this personal data and delete it on a case-by-case basis.

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 Server: Right of access by the data subject article. In this article, we provide workarounds to ensure that you can remove personal data for a specific user, if required. Some of the workarounds require running 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

All workarounds are compatible with 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. 

Workaround

As with all recommendations and workarounds, you should test and validate these processes in a test environment prior to rolling them to your production environment.

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.

Anonymize user data in Jira

Before you begin

You must  have the JIRA Administrator or JIRA System Administrator global permission to be able to manage users in JIRA applications.

  1. Select User Management.
  2. Find the user in the user list using the filter form at the top of the page.
  3. Click on user Full name in the "Full name" column.
  4. Store data from "Account information" section for later usage:
    1. Username
    2. Full name
    3. Email
  5. Clear 'Remember My Login'
    1. Choose Actions > 'Remember My Login' Tokens, Remember My Login popup will be displayed.
    2. In the popup click Clear All
  6. Edit username, full name, email, 'Active' (view this page for more info on editing users.)
    1. Click Edit in the Operations column.
    2. Make the changes to username, full name, or email address, uncheck Active and click Update to finish.

      A user cannot be deleted if they are currently a component or project lead. An error message will appear asking you to assign another user first.

      A project lead can be changed in following way:

      1. Choose  > Projects, and select the relevant project.

      2. Choose Users and roles in the project sidebar.

      3. Click Edit defaults, "Edit project lead and default assignee" popup should be displayed, change Project Lead and click Update.

      Component leads can be changed by following the instructions here.

      There are also unsupported scripts for updating a component or project lead below.

  7. Clear user properties

    1. Choose Actions > Edit Properties. The Edit User Properties screen will be displayed.
    2. Delete properties using Delete link in Actions column

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).

Delete user avatar in Jira

Before you begin

You must  have the JIRA Administrator or JIRA System Administrator global permission to be able to manage users in JIRA applications.

  1. Select User Management.
  2. Find the user in the user list using the filter form at the top of the page.
  3. Click on user Full name in the "Full name" column.
  4. Click View Public Profile, user public profile page should appear.
  5. Follow the instructions on Managing your user profile to manage the user's avatar (delete user avatar and use default avatar).

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.

Important note

You will only get search results for entities you have the right to view. Make sure you have full admin rights if you want to search for all instances of PD.

There may be some fields you don't have access to. If "none" is selected for custom field Search Templates, then JQL searching will omit this field. Such fields have limited processing and nobody will be able to perform the search by this field's value.

  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):

Always back up your data before performing any modifications to the database. If possible, test any change, insert, update, or delete SQL commands on a staging server first.

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.

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.

If you use 3rd party add-ons that rely on the user_key, modifying the user_key could cause the add-on to break.

Changing the user_key (only when the user_key holds PD)

Always back up your data before performing any modifications to the database. If possible, test any change, insert, update, or delete SQL commands on a staging server first.

In order to successfully perform user data modification you must modify the provided SQL script files specific to your database, following the steps below.

  1. Use the user_key obtained in Step1

  2. For each SQL statement, you need to:
    1. replace the pattern <CURRENT_PD_VALUE> with the user_key value,

    2. replace the pattern <NEW_PD_VALUE> with a new value you want to store and keep in a database (a new user_key value - anonymised or pseudoanonymised pattern).

  3. There should be two SQL scripts for each database table:

    1. A "select" SQL script that should be used to determine what kind of changes will be done by the second "update" script.

    2. An "update" SQL script for data modification.

  4. Use these SQL scripts for JIRA Core and JIRA Software:

    Scripts

    UPDATE oracle • mysql • postgresql • mssql

    If you're running JIRA Service Desk , execute these scripts after you've executed the JIRA Core scripts:

    Scripts

    UPDATE oracle • mysql • postgresql • mssql

  5. Review all your queries, table by table.

  6. For each table, execute the "select" script and carefully review potential changes, then execute the "update" script.

    1. If a suggested change is not acceptable for some of records you'll need to update these manually.

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 etc.). In order to search all potential places that personal data could be stored, you need to run a SQL query against the database.

Finding PD in other entries

Dealing with free-form text fields

Always back up your data before performing any modifications to the database. If possible, test any alter, insert, update, or delete SQL commands on a staging server first.

In order to successfully perform user data modification you must modify the provided SQL script files specific to your database, following the steps below.

  1. Search for the following PD obtained for the specific user and related data:

    1. Username

    2. User key (if differ from Username)

    3. Full name,

    4. Email

  2. For each SQL statement, you need to:

    1. replace the pattern <CURRENT_PD_VALUE> with the PD value that you want to change,

    2. replace the pattern <NEW_PD_VALUE> with a new value you want to store and keep in a database (a new PD value - anonymised or pseudoanonymised pattern).

  3. There should be two SQL scripts for each database table:

    1. A "select" SQL script that should be used to determine what kind of changes will be done by the second "update" script.

    2. An "update" SQL script for data modification.

  4. Use these SQL scripts for JIRA Core and JIRA Software:

    Scripts

    UPDATE oracle • mysql • postgresql • mssql

    If you're running JIRA Service Desk , execute these scripts after you've executed the JIRA Core scripts:

    Scripts

    UPDATE oracle • mysql • postgresql • mssql

  5. Review all your queries table by table. Each query description provides information about what kind of data it contains, whether the data can be updated directly in JIRA using the UI (preferred) and whether REST API endpoint for modifying data is available (preferred).

  6. For each table, execute the "select" script and carefully review potential changes, then execute the "update" script.

    1. If a suggested change is not acceptable for some of records you'll need to update these manually.

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.

This script is just a proof of concept, and is not supported by Atlassian.

See the script

Source:

To select data:

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

To update data:

> 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

This script is just a proof of concept, and is not supported by Atlassian.

See the script

Source:

To select data:

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

To update data:

> 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:

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

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". 

Additional notes

There may be limitations based on your product version.

Note, the above-related GDPR workaround has been optimized for the latest version of this product. If you are running on a legacy version of the product, the efficacy of the workaround may be limited. Please consider upgrading to the latest product version to optimize the workarounds available under this article.

Third-party add-ons may store personal data in their own database tables or on the filesystem.

The above article in support of your GDPR compliance efforts applies only to personal data stored within the Atlassian server and data center products. To the extent you have installed third-party add-ons within your server or data center environment, you will need to contact that third-party add-on provider to understand what personal data from your server or data center environment they may access, transfer or otherwise process and how they will support your GDPR compliance efforts.

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.

Last modified on May 24, 2018

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.