Weekly GDPR API status development update - March 7th

Of course I need to set the header when calling the REST API to not receive usernames anymore (this is working fine btw), but that was not my concern. My concern was about the webhook data we receive, for example for jira:issue_updated. Setting the gdpr:true flag should influence the webhook data, because this flag is related to the Connect API behavior (as youā€™ve mentioned), right? The webhook data is not coming into our app by us calling an API in Jira, but instead Jira/the Connect API is calling an endpoint on our side. So, when I set gdpr:true, I assume I should only receive webhook data which does not contain username or user key information anymore, right? Or am I confusing this with the HTTP header x-atlassian-force-account-id ?

For example, a webhook (with gdpr:true in my case) now still contains the following data:

{
            "timestamp": 1552059883865,
            "webhookEvent": "jira:issue_updated",
            "issue_event_type_name": "issue_updated",
            "user": {
                "self": "...",
                "name": "addon_com.k15t.backbone.backbone-issue-sync",
                "key": "addon_com.k15t.backbone.backbone-issue-sync",
                "accountId": "557058:...",
                "emailAddress": "com.k15t.backbone.backbone-issue-sync@connect.atlassian.com",
                "avatarUrls": {...},
                "displayName": "Backbone Issue Sync for Jira",
                "active": true,
                "timeZone": "Europe/Berlin"
            },
            "issue": {...}
}

I was assuming that setting the flag will remove name, key and emailAddress (and I guess some more) from this data. This example is now for an app/system user, but Iā€™ve seen the same for normal users as well. Is my assumption correct or am I wrong here?

Update #2:
Further testing reproduces the problem with the sidebar, and we have raised this issue for fixing it: [ACJIRA-1736] - Ecosystem Jira
We are holding on to the changes in Connect that removes those context parameters (user.id and user.key). We will verify and release that change once the ACJIRA ticket above is fixed.
cc: @charlie

1 Like

Thanks for the update @natashbar! We will watch ACJIRA-1736.

I am unable to retrieve an avatarUrl when calling the Jira endpoint /rest/api/3/groupuserpicker while having showAvatar=true and x-atlassian-force-account-id header set to true. Setting the x-atlassian-force-account-id header to false does return an avatarUrl as expected.

Hi @f.demir,

Please track progress for this issue in ACJIRA-1732

Cheers,
Anne Calantog

1 Like

I havenā€™t got an answer to my previous reply in this thread so far, but Ivan commented on this issue ([AC-2433] - Ecosystem Jira) that it seems I was right with my assumption that webhooks still contain the name and key even when opted in. Just wanted to let you know about it.

// Edit: Okay, I understood that comment & issue in a wrong way. It is about the query parameters, not the webhook payload data. So maybe itā€™s not related. Anyway, it would be interesting to get an answer about my question above.

Hi @anon28347317,

Thanks for reporting that issue. If you think this is a bug and something we should look into, please file a bug report here

Cheers,
Anne Calantog

Hi @akassab,

Is the ā€˜apiMigrations.gdprā€™ flag applicable for Bitbucket Cloud apps? Weā€™ve added the following code to the app descriptor:

"apiMigrations": {
    "gdpr": false
  }

After that, there is no way to install the app:

Could you please advise us on how to proceed?

Thanks,
Alex

How do you implement internationalization now since loc context parameter is removed?

https://developer.atlassian.com/cloud/jira/platform/internationalization/

I was searching this for a while but couldnā€™t find an answer.
What I found:
AC-2417
but no alternative

There is a locale parameter in User object, but it can be null after new privacy settings Myself

Hi @maciej.dudziak,

I donā€™t think there is a real solution right now. See @dmorrowā€™s and my discussion here: Weekly GDPR API status development update - February 20th - #25 by dmorrow

Hi @alexkuznetsov -

Great name btw :wink: . This flag wonā€™t work for Bitbucket apps - sorry for the confusion. Its Jira and Confluence apps only. Iā€™m interested in learning more about what youā€™re blocked by though (looks like you intended to set the flag to false ). Curious if you posted your blocker on this thread.

Thanks,
Alex

Hi @jens

Thank you for pointing me to that discussion

@dmorrow I think AP.user.getLocale() would be sufficient for us

I couldnā€™t find any open ticket so I created [ACJIRA-1749] - Ecosystem Jira

Hi @maciej.dudziak - This ticket already exists for locale. I also included in this weekā€™s Weekly Update.

1 Like

Hi @anon28347317 - Thanks for raising it with us. Iā€™m trying to chase down an answer. My expectation would be that if optā€™d in webhooks would respond and only pass accountID. Sounds like this is not the case and Iā€™m trying to refresh my memory on why.

@akassab, Iā€™ve created a devhelp ticket DEVHELP-2415 as suggested by Anne. In that ticket I got the response that webhook payload data does not change with the GDPR opt-in. Only after the deprecation period weā€™ll see a difference there. I find it quite interesting that there is a different behavior compared to the current open/in progress issues. For example, when opting in the user data from query parameters will be removed (as soon as the issue is resolved), but not from webhook payload data?

@anon28347317 - Thats my understanding as well. Iā€™ve clarified this in the opt in behavior section on this weekā€™s post. Out of curiosity, does this create a critical blocking issue for you or can you work around it? (Trying to assess priority).

Hi @akassab ,

Gotcha! Thank you for your quick response.

The screenshot above was made when we set the flag to false. Therefore, the app works fine if we donā€™t use this flag.

Thanks,
Alex

@akassab We have created a ticket to get the visibility controls available but we are waiting since a week to get this approved.
As we cannot test it ourselves: Can you confirm that GET /rest/api/3/user/search still return the user even if the visibility of email is set to false?

GET /rest/api/3/user/search
Returns a list of users that match the search string and property.

Query parameters

query
string

A query string that is matched against user attributes ( key , name , displayName , and emailAddress ) to find relevant users. The string can match any part of the attributeā€™s value. For example, query=john matches a user with a displayName of John Smith and a user with an emailAddress of jane.johnson@example.com . Required, unless username is specified.

I am also waiting on an answer to this (see my thread about whether we can still search by email after the GDPR migration happens). Itā€™s holding up some of my development work because I donā€™t know whether I can assume my application can translate email to accountID.

@david.gunter Thanks for the link - havenā€™t seen it.
So yeah -letā€™s see :slight_smile: