Weekly GDPR API status development update - March 7th

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: