Anonymization of user names

[Anette Noll]

Hi to all, my name is Anette and I am a project management assistant. Since half a year I am introduced to the Jira world and administration by our company Jira administrator. This colleague will soon no longer be available for questions and exchange, so a good moment to "knock on the door of the Jira community".

I would like to start with a question within the GDPR context.

How can names of terminated users be anonymized in existing issues/fields (at least assignee und reporter)? Is there a Jira immanent possibility?

[Domenico Manzo · Accepted solution]

@Anette Noll 

I hope this guide will assist to you solve the issue https://actonic.atlassian.net/wiki/spaces/GDPR114/pages/6261080183/How+to+anonymize+disabled+or+deleted+user+in+Jira

If you have any question, just let me know.    

[Anette Noll]

Thank you for quick response! I will have a closer look at it as soon as possible.

[W Bot]

My suggestion would be to change the user name just before disabling the user.  That should change it throughout the system in older issues. (RE: Cloud).

Is this pure GDPR compliant? Not sure, but I think it might help..

Beyond that, you may need to create a "GDPR redacted" user account and using JQL and bulk change,  change all the affected assignee. reporter fields and other relevant user picker fields from the "to be disabled" user to the "GDPR Redacted" user.  I believe you'll have to do this before disabling the account.

[Anette Noll]

Thank you for response!  This is a vey pragmatic solution, that can be implemented in short term. My first thoughts went in the same direction. The problem is, that I can't make a bulk change on issues that are already resolved. Or have I overlooked something?

[W Bot]

It shouldn't be a problem technically to make almost any changes on resolved issues using bulk issue change as an admin.

The only thing you can't do on an issue in this manner is actually resolve something (from the "edit issue" bulk change..) or change the resolution value itself. You have to do that using transitions.

[W Bot]

Either the name change or the bulk change can work, I guess it's really a matter on how anonymous it has to be.

Changing the name to a long numeric string then disabling the account eliminates the name of the individual without changing the history of their actions.  Although somebody in HR should have the "awepiuewr78" = "Person Departed" key I suppose.

Also changing assignments and reports alters that history to a single "blended" user that combines all departed persons,  This makes it even more private at the high level without reviewing the issue history (I would think you would do both in this case to alter the history records).

Which is appropriate seems like an organizational question.

hope this helps!

[Amir Katz (Outseer)]

disclaimer - not a GDPR expert...

I don't understand how GDPR is relevant here. If someone has worked in a company and they interacted with Jira, why is this fact considered a "secret" that needs to be redacted?

In my mind, it goes against the well-established paradigm that you never go back and change the history. 

You can of course do the user rename from JohnDoe to PastEmployee_1234, and the bulk update, but then you will have to keep a mapping of the new (anonymous) name to the old (real) name somewhere, so you just move the problem to another place.

[W Bot]

Hi Amir,

I certainly agree that not changing history is a very valid concern, and in general I agree that you should be cautious when doing this.  

I don't know the OP's situation, but maybe the mapping might move the problem into secure HR files instead of the relatively open and visible Jira instance.

Also, on a different tack for other new admins, I will say it's important to change the assignment of any unresolved issues to either un-assigned or another user before deactivating the old user.  Not doing so can cause headaches like having to reactivate the old user to get it done, or automation can fail if it tries to grab an invalid user.

[Amir Katz (Outseer)]

All good points. The last one is something that I also ran into...