Jira and Tempo API : username and userkey

[Administrateur]

2 Questions : 1 for Tempo and 1 for Jira.

Hi,

Since years, we use Jira Server with Tempo. As everyone know, if we want to continue to use these products, we will have to go to the cloud.

I'm in charge to look what is possible and what is not possible if we go to the cloud. So far, the Jira and Tempo API are very helpful.

But I have one problem. Before that, let's talk about what we do where I work.

As for now, we have Jira and Tempo installed in our servers. We created read only SQL views to have data about Jira issues, Worklogs, Users, Groups and Teams.

We use all this data in order to make links to other other systems (outside of Jira), some created by us and other from third parties.

In the Jira version, for the users, we use the username and the userkey. The username is the login we import from our active directory. So for example, for John Smith, it could be smij01. The userkey can be the same than the userkey (for older users), but for the new ones since an update, it's something like JIRAUSER12345.

From what I understand (and with the tests I did), with the Tempo API, the workerKey and the updaterKey use the userkey, so something like JIRAUSER12345 is returned. But what we need in order to make link to other systems we have is not the userkey, but the username (active directory login like smij01). So I was thinking: no problem, let's use the Jira user API to know who are who, and to make links between Tempo data and our systems.

But here's the problem. According to this article, when the deprecation transition period will be over, we will not be able to use or obtain the username or the userkey of any users. Instead, we will have to use the accountId. We will not be able to us the username and the userkey in the search, but also it will not be returned in any way.

https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-user-privacy-api-migration-guide/#user

From what I have read, the accountId is an Id for users and it's something like 71121:6b1f7b04-6e9e-4276-b4d8-4d7b1678e327 or 5f3becff3ab35c003f30d837.

So here's my questions...

For Tempo : How will it be possible to make the link between the workerKey/updaterKey returned by the Tempo API and the user returned by the user returned by the Jira user API?

For Jira : If I can't get the username anymore, how can I automatically make the link between the data returned by the Jira API (no username) and the other systems we use (that work with the username)?

Thanks,

Eric Blais

[Andy Heinzer · Accepted solution]

Hi @Éric Blais 

In regards to the Tempo side of things, I would recommend creating a support case over with Tempo directly.  You can do this by using their customer support portal.

As for the Atlassian side of things, you are correct that our Cloud platform won't be able to return values such as userkey in the future.  Instead the push has been to for Cloud to use accountId as a unique and unchanging identifier value for a user's account.  The older userkey values in Jira server were initially intended to never change, even if a username did change in Jira (which was only possible after Jira 6.0 and higher versions).  However with GDPR changes, keeping that value the same as the original username isn't always feasible.  Which is why the userkeys started to change to the JIRAUSER12345 format instead.

Also since Jira Cloud does not provide direct access to the SQL database, you will need to use the REST API in order to retrieve user information.  This just solidifies the need to adjust or update your other integrations to use the accountId once you move into Jira Cloud.  I'm sorry, I don't know that I will be able to provide a specific set of steps needed to complete this change to your other tools, but I'm confident they will need to use accountId instead here.

You could also create a migration support ticket with Atlassian over in https://support.atlassian.com/contact/

It is outside the scope of our support offerings to create or modify external customizations, but we always recommend when users are planning to migrate to our Cloud services to create these support cases so that we can investigate further.

Andy