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: