GDPR changes in Jira

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

Anonymizing users

Our ultimate goal is to give Jira admins the tools to anonymize users and any related personal data that appears in Jira. To fulfil it, we're planning to add the following set of capabilities to Jira admin pages:

• Changing user key and username of an existing user
• Anonymizing user profile
• Deleting or anonymizing personal data that appears in Jira

To let your app work with these new capabilities, we've created 4 new extension points that will inform your app about a user being anonymized and the involved actions.

Extension points & planned workflow

The following actions will help you better understand the planned 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). Anonymization will be triggered by an administrator for a single user.  The process is a background, non-blocking task.

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.

In case something goes wrong

Jira will collect exceptions thrown by the extension points and present them as warnings to the administrator once the process finishes. Admins will then have an option to retry the operation. In this case, the extension point will receive exactly the same data as it received the first time - the original and the anonymized value.

For a sample implementation of the extension points, you can refer to the jira-reference-plugin and study the implementation classes such as ReferenceUserKeyChangeHandler and the corresponding entries in the atlassian-plugin.xml file. For example: 

<user-key-change-handler key="ref-plugin-user-key-change-handler" class="com.atlassian.jira.dev.reference.plugin.user.ReferenceUserKeyChangeHandler" />

Updates ensuing from anonymization

We will update all of Jira’s native entities, like custom fields, comments, or work logs, even if they are created by your app. 

We will not introduce changes to your Active Objects database tables or the extensions that Jira is unable to understand without your app (e.g. custom workflow transitions).

List of extension points

You can find all of the extension points listed below in the  com.atlassian.jira.user.anonymize package.

We need your feedback!

This is the initial shape of the SPI. Note that all classes are annotated as @ExperimentalSpi and it's likely that they will change. We're presenting it to collect feedback from you to refine the SPI before making it final. Please do share your thoughts by leaving comments in this community post.

Generating user keys

We're introducing 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 data. 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.

Testing the change

This change is hidden behind a dark feature flag. To enable it:

1. Go to <Jira_URL>/secure/SiteDarkFeatures!default.jspa 
2. Add the com.atlassian.jira.user.dbIdBasedKeyGenerationStrategy.enabled flag.

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.

What to test

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