Trying to access user email from issue assignee: GDPR overkill?

Hi all. I have a simple script that is called every on automated deployment (i.e a merge to the master branch) that fetches information about the associated Jira ticket and then notifies the ticket assignee on Slack. Unfortunately to do that I need the issue assignee’s email address, and it looks like Atlassian has locked this down.

At the moment I’m reduced to maintaining a lookup table of names to email addresses, which is crazy. It looks like there is indeed an API for this, but it looks like it’s only available for Forge/Connect apps.

Is this really the only way to get a sensible global identifier for a user (i.e an email!)? It’s users in my organisation, and I have admin access, so I know their email addresses (after all: I have a hard-coded mapping in my script!).

Are Atlassian expecting me to write my entire integration script in a Forge app? I have absolutely no requirement for any UI here: it’s purely a backend script kicked off via a Gitlab Pipeline.

Any help appreciated. I’d rather not have to move my nice Python code into JS unless I really have to!

Ah yes… welcome to the Atlassian predicament.

Let’s do a little trip down memory lane. The year is 2019 and Atlassian is scrambling to implement GDPR, which came into effect since May 2018.

For most companies, GDPR is a mess, but for Atlassian, it is a true nightmare. For a couple of years now, Atlassian has been migrating users to their new Atlassian ID infrastructure, which it created to scale her somewhat new Cloud offering.

You see, initially Atlassian thought it could get away with just serving “hosted Jira” as a Cloud solution. But that really didn’t scale well and resulted in a massive AWS bill. So they decoupled her Cloud & on-premise products and started to rethink identity management in Cloud. She came up with a brilliant idea: one Atlassian ID to rule them all. Individual users would get an Atlassian ID and those Atlassian ID could be used with all Atlassian products and linked to an indefinite amount of company instances. In theory one could have a personal Atlassian ID and keep that ID when they switch employers.

Then GDPR came along and Atlassian was completely f*cked. Because not only was the Atlassian ID coupled to individuals, those individuals could also use the same Atlassian ID for consumer facing products (like Trello and Bitbucket) as well as for business use.

That means that Atlassian was both a Data Controller as well as a Data Processor for that same user, making the whole “consent” issue a lot more difficult compared to other B2B SaaS solutions. While the rest of the SaaS world simply said that they either were Data Controller (b2c) or Data Processor on behalf of the company and that consent was not required because of contractual clauses (B2B), Atlassian had created a mixed bag.

It became even worse because Atlassian also had a Marketplace where Marketplace Partners were getting access to Atlassian data on behalf of Atlassian customers, which included PII from Atlassian ID for which Atlassian was responsible of the data.

So they did what any normal company would do: they created a legal monstrosity. The gist is: Atlassian ID is a one-on-one relationship between Atlassian and the individual, and Atlassian is the gatekeeper of all PII related to the Atlassian ID.

Even if your employees use their work email, they have created their Atlassian ID accounts as individuals, entering into a separate legal construct with Atlassian with regard to the Data Controller/Data Subject relationship that is not related to the agreement they may/may not have with their employer.

And Atlassian is taking the responsibility of safeguarding this data very, very, very serious. Meaning that you will not get access to that data unless absolutely necessary in a very controlled environment.

So yeah, short answer is that you won’t get this data from Atlassian even if you somehow feel that this was your data to begin with.

2 Likes

Thanks for all that info Remie: I now understand their paranoia.

But if I did want the user’s email, then presumably I could do it inside a Forge app using web triggers?

Yes, that should work. See also Get user email - new OAuth 2.0 scopes? - #2 by SeanBourke