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 adisplayNameof John Smith and a user with anemailAddressof jane.johnson@example.com . Required, unlessusernameis 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 