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:
- 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). - 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. - Deleting/anonymizing the data: Jira will execute
UserAnonymizationHandler#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
UserKeyChangeHandler#updateandUserNameChangeHandler#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.
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.