Server GDPR timeline and questions

Jira Development Jira Server
1

Hi there,

I’m wondering what’s the timeline for the GDPR changes on Jira Server. We are already getting prepared for it, but as we don’t have a final implementation yet to work with (APIs are experimental) would be nice to have an idea of when it will be released so we can plan accordingly.

In addition to more information about the timeline, I’ve got a couple questions:

  • Will the user renaming/anonymisation be in bulk i.e. many users at a time, or it will be done one users at once only? My concern here is performance.
  • Are there any examples on how these listeners will be registered?

Thanks!

2 Likes
2

Hello Vitor!

The process will always be triggered for a single user and will run in a background task.

The extension points are registered using module descriptors in the atlassian-plugin.xml file. As an example, ReferenceUserKeyChangeHandler is registered like this in our reference plugin:

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

With regards to the timeline, unfortunately, we can’t make any hard commitments, but for sure it won’t be in Jira 8.3. Having said that, it is extremely unlikely that any significant change will happen to the SPIs.

We have recently slightly updated GDPR changes in Jira | Atlassian Support | Atlassian Documentation to cover answers to more questions, e.g. error handling/retry mechanism, that you might also find useful.

Please let me know if you have any further questions. :slight_smile:

3

Hi @drauf

Thanks for the information provided :slight_smile:

Is that possible at this moment for us to trigger this process manually, in order to simulate what the UI is going to trigger when the final version is available?

This would bring more confidence that we are in the right path, and also, allow us to work on some experiments regarding having a single build for previous versions of Jira (which doens’t have the new APIs) and for the new ones (8.2 or 8.3 and so on).

Thanks again!

1 Like
4

Hey @fmunhoz,

You can refer to com.atlassian.jira.dev.backdoor.UserAnonymizeBackdoor in the jira-func-test-plugin to see how we set up our integration tests for this area. It was added in Jira 8.2.

As a step by step breakdown, you will need to use AnonymizeUserService that’s available through @ComponentImport.

First, you will have to create an anonymization request and validate it, e.g.:

        final AnonymizeUserService.AnonymizeValidationResult validateResult = anonymizeUserService.validateAnonymize(AnonymizeUserService.AnonymizeUserRequest.builder()
                .targetUser(userKey)
                .rerunPluginPoints(rerunPluginPoints)
                .oldUserName(oldUserName)
                .oldUserKey(oldUserKey)
                .newOwnerKey(newOwnerKey)
                .executor(authenticationContext.getLoggedInUser())
                .asyncTaskContext(Contexts.nullContext())
                .build()
        );
        if (!validateResult.isValid()) {
            return Response.status(Response.Status.BAD_REQUEST).entity(
                    validateResult.getErrorCollection().toString()).build();
        }

Then, you can actually perform the operation using the validation result from the last step:

        final AnonymizeUserService.AnonymizePerformResult performResult = anonymizeUserService.perform(validateResult);
        if (!performResult.getReport().isValid()) {
            return Response.status(Response.Status.BAD_REQUEST).entity(
                    performResult.getReport().toString()
            ).build();
        }

Finally, we return a custom object that holds some outputs from the operation, just to perform asserts in the integration tests:

        return Response.ok(
                new AnonymizePerformResult(...)
        ).cacheControl(never()).build();

Hope this helps. :slight_smile:

4 Likes
5

@drauf thanks for the suggestions. We are in the process of trying it out on our side.

During our internal discussions a new question has emerged.

If our Jira app is installed, but disabled, and the Jira administrator anonymizes any user, our extensions points are not going to be triggered, which makes sense.

This would generate an inconsistent state when our app is enabled again, if the mentioned anonymized user was being referenced by any of our app entities/tables.

Is Jira going to show any warning messages for the Jira admin about potential problems like that? I know this is an edge case, but it might ocurr in some cases.

5 Likes
6

@fmunhoz thank you for your suggestion.

I have added this to our backlog so that we don’t lose track of the issue. Off the top of my head, a warning in the UI looks reasonable, but it will definitely need input from a designer, especially since we want to provide REST endpoints too.

1 Like
7

@drauf just to let you know we were able to use the AnonymizeUserService to trigger the process.

Thanks a lot for the suggestion, it made things much clear, since now we can have a better idea how this feature will work and it’s impacts.

Although this functionality is still in progress, so we will be waiting for the next versions to validate the process as a whole.

Cheers.