Incoming webhook. Changelog from/to values should use account id when apiMigrations's gdpr = true

Description

Hi team,

As far as we can tell, there is no way of telling Jira to use account ids instead of usernames inside changelogs of issue webhooks.

The full discussion can be found in the community.

https://community.developer.atlassian.com/t/privacy-changelogs-and-username/26761/3

It would be nice that the opt-in apiMigrations changes the webhook data the same way x-atlassian-force-account-id’:true changes the rest responses. (another flag in descriptor doing the trick is also fine)

if this is not updated, our addon would still need to do the user lookup by username in order to patch incoming webhooks.

Cheers
Fernando

Environment

None

Activity

Show:
Ivan Babikov
May 6, 2019, 5:24 AM

Hello all,

Account IDs are returned in place of user names if the incoming request had opted in (by setting the x-atlassian-force-account-id to true).

I see again that to receive a correct webhook we need to send a correct request. The problem is that in our scenario no requests go to Jira - we receive webhooks when users change Jira issues.

Ben Kelley
May 3, 2019, 5:36 AM

I can confirm that tmpFromAccountId/tmpToAccountId are not returned for multiuser fields. The change for this issue only affected single user fields.

Account IDs are returned in place of user names if the incoming request had opted in (by setting the x-atlassian-force-account-id to true).

 

Fernando Boucquez (PPL)
May 2, 2019, 1:09 PM
Edited

I have just tried multiuser pickers and Jira is still sending usernames (all my GDPR flags have been turned on for a while). No tmpFromAccountId or tmpToAccountId at all.

It seems like this is a pretty buggy, incomplete and temporary solution. Unsure how this issue is closed.

I guess I will keep the workaround of patching webhook's changelog with changelogs from the Rest API for a while.

Raimonds Simanovskis
May 2, 2019, 10:35 AM

After some additional testing, we found out that in our case "tmpFromAccountId" is always null. When we add the "x-atlassian-force-account-id:true" header then we see the correct accountId in the "from" field but still "null" in the "tmpFromAccountId".

So it seems that there is a bug that "tmpFromAccountId" is always null.

You can see this problem also in https://ecosystem.atlassian.net/rest/api/2/issue/ACJIRA-1795?fields=&expand=changelog

Raimonds Simanovskis
April 30, 2019, 6:10 PM

I just noticed in one our issue that the changelog entry for an assignee change has a user key in "from" field but "tmpFromAccountId" is "null". This specific user key is for an active user and when this user was an author for other changes then the "author" object contains its "accountId".

So I am wondering how this changelog use key to accountId migration was done. Was it done as a batch job and the results were stored (and in this our case for some reason a corresponding accountId was not found) or is this accountId lookup done dynamically?

Where would it be good to report this identified problem for a specific changelog entry?

Fixed

Assignee

Ben Kelley

Reporter

Fernando Boucquez (PPL)

Labels