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 @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 . 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.
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
stringA query string that is matched against user attributes (
key
,name
,displayName
, andemailAddress
) to find relevant users. The string can match any part of the attributeās value. For example, query=john matches a user with adisplayName
of John Smith and a user with anemailAddress
of jane.johnson@example.com . Required, unlessusername
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