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.
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:
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
getAffectedEntitiesmethod 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.
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
Deleting/anonymizing the data
Jira will execute U
serAnonymizationHandler#updateto delete or anonymize user’s personal data and entities that can be accessed only by the user (for example, private dashboards).
Anonymize user keys and usernames
Jira will execute
UserNameChangeHandler#updateto 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
This method finds and displays all occurrences of user's data and any related entities.
It's used in all of the following classes.
|Described in each extension point.|
||This method will transfer the ownership of various entities to a different user. It will simply update the userkey to a different one.||Javadoc|
This method will delete or anonymize user's data.
||These methods will update the user's user key and username to their anonymized versions (e.g. johndoe → JIRAUSER10100).||Javadoc|
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.
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
We’re changing this approach so that all user keys for new users (no changes for existing users) have the following format:
Testing the change
This change is hidden behind a dark feature flag. To enable it:
- Go to
- Add the
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.