Right to erasure in Portfolio for Jira Server and Data Center
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.
Personal data for a specific Jira user can be used and stored in Portfolio for Jira. These workarounds will help you anonymize or remove personal data for a specific user in Portfolio for Jira. They only apply to Portfolio for Jira, and will not anonymize or remove personal data of a user in Jira, Jira Software, or any other product. To anonymize or remove personal data in other products, see Server and Data Center GDPR support guides.
All workarounds are compatible with Portfolio for Jira 2.13.0 and later.
Before getting started
As Portfolio for Jira is built on top of Jira, we recommend that you go through the workarounds for Jira before going through the workarounds specific to Portfolio for Jira.
Please follow these general steps:
- Go through the workarounds for Jira.
- Go through the workarounds for Portfolio for Jira.
- Re-index your Jira instance. Portfolio for Jira uses in-memory cache to speed things up, and even if personal data is removed from the database, it could still remain in cache until the next re-indexing.
Portfolio for Jira uses specific Portfolio for Jira usernames to offer a seamless experience, which means these usernames are stored in database tables specific to Portfolio for Jira. When a user is removed from Portfolio for Jira, the username may still remain in those database tables. This workaround will help you clear a specific username from the database tables specific to Portfolio for Jira.
What cannot be deleted
To prevent any confusion, and for Portfolio for Jira to keep functioning properly, we recommend that you replace all personal data elements in Portfolio for Jira with anonymous data elements whenever a user is deleted or anonymized from Jira. It's also worth noting that deleting usernames and emails can run the risk of breaking Jira and Portfolio for Jira. We recommend that you replace those data elements with anonymous elements that do not identify the user, instead of deleting users.
As you go through the workaround provided for anonymizing users, please choose an appropriate and consistent display name that will be used to replace values with, such as
Anonymizing a username
Go to this directory https://bitbucket.org/atlassian/gdpr/src/master/portfolio_db_queries/ and download the pre-populated SQL scripts for your respective database.
- Open those SQL scripts in your preferred text editor.
Modify the provided SQL scripts with the following changes:
- Replace <OLD_VALUE> with the personal data element that you're searching for.
- Replace <NEW_VALUE> with "new personal data element value".
Stop your Jira instance. See Start and Stop JIRA applications for instructions.
This step is required because Jira caches a lot of data, and because directly updating the database when Jira is still working could cause data loss or inconsistencies.
Manually execute the corresponding SQL scripts, table by table. For each table, execute select script. If the change is acceptable, execute update script. If the change is not acceptable, you'll need to update the record by hand.
- Restart your Jira instance.
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.