Important: GDPR changes in Jira Server

Reading Time: 3 minutes

To improve the compliance of Jira Server with General Data Protection Regulation (GDPR), we will be introducing a set of changes in Jira over the next few months. Read on for all the details, dates, and the impact these changes will have on your apps.

1. Right to be forgotten

The most impactful changes are related to the 'right to be forgotten'. This will include the following new capabilities for admins in Jira:

  • Changing user keys and usernames of existing users
  • Anonymizing user profiles
  • Deleting or anonymizing personal information that appears in Jira

To let your app work with these new capabilities, we are going to create 4 new extension points that will inform your app about users being anonymized and the involved actions.

Extension points & planned workflow

All of the new extension points will be in the com.atlassian.jira.user.anonymize package. The following actions will help you better understand the whole anonymization flow and how the extension points fit into it:

  1. Getting the data: Admins will be able to anonymize users through a new page in the Jira administration. After choosing a user, Jira will execute the getAffectedEntities method in all of the new extension points to display the occurrences of user's data and any related entities (e.g. Component lead).
  2. Transferring the ownership: Some of the related entities will not work properly with inactive users and will need to be transferred to a different user, chosen by the admin. For example, an inactive Component lead might break the Default assignee option. To transfer the ownership, Jira will execute OwnershipTransferHandler#update.
  3. Deleting/anonymizing the data: Jira will execute UserAnonymizationHandler#update to delete or anonymize user's personal data and entities that can be accessed only by the user (for example, private dashboards).
  4. Anonymize user keys and usernames: Jira will execute UserKeyChangeHandler#update and UserNameChangeHandler#update to update the user's user key and username to their anonymized versions (e.g. johndoe -> JIRAUSER10100). These properties might be stored as foreign keys in the database.

To learn more about these extension points, refer to Javadocs that will be included in the Jira 8.2 Early Access Program (EAP), or see Preparing for Jira 8.2.

Expected date

We are releasing the initial shape of the SPI in the first Early Access Program (EAP) of Jira 8.2.

Please be aware that all of the related classes are annotated as <code>@ExperimentalSpi</code> and it's likely that they will change.

The current goal is to collect feedback from you to refine the SPI before making it final.

Impact on apps

These changes will have a major impact on apps for Jira Server, because changing the user keys for existing users might break things.

2. Generating user keys for new users

Another major change is a new way of generating user keys for new users. The reason behind it is that we want to reduce the number of places where we store users' personal information. Currently, user keys are similar to usernames, and these often contain actual names of their users.

Current state

Currently, the user key is the same as username, lowercased. For example, user Admin will get a user key admin. If there's a naming conflict, the user key will be set to a value like ID10100.

We're changing this approach so that all user keys for new users (no changes for existing users) have the following format: JIRAUSER10100

Expected date

This change will be available to test in the first Early Access Program (EAP) of Jira 8.2, hidden behind a dark feature flag (com.atlassian.jira.user.dbIdBasedKeyGenerationStrategy). This should give you time and means to prepare and test your code against it.

We will enable this new behavior by default in upcoming releases. The dark feature is there to give you a head-start, a way to check and prepare your apps.

Impact on apps

This change may break any code that makes assumptions similar to userkey == username. If your code differentiates between the user keys and usernames, you shouldn't need to make any changes.

Realistically speaking, we suspect that it will uncover unexpected behaviors in your apps. In our case, we discovered two bugs in the production code, and had to modify a number of tests.