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:
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
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.
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.
Great name btw . 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.
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).
@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.