Bitbucket Cloud GDPR Clarifications

Hi,

I’m upgrading our app to handle the GDPR changes and just want to confirm a few things/ask a few follow ups:

  • It sounds like the concept of a user profile is going away based on an Atlassian employee’s post here. Will there be some equivalent link for this user in the workspace? We display user’s avatar next to a link to their bitbucket profile in our app and would like to maintain a similar experience, even just linking to user activity in a workspace would be nice.
  • In the migration guide, it mentions that the avatar link “should be considered opaque”. Can you give more context as to what this means? Again, we’d love to display their picture next to their recent changes and want to make sure this is possible.
  • Will general (non-API) links that use {username}/{repository_name} continue to work? (for instance something like “https://bitbucket.org/mnomitch/personal/src/master/”) Or will these be replaced by uuid as well?
  • Will the “repository.full_name” change to show the uuid instead of username if a user is the owner?

Thanks a lot!

2 Likes

In addition: would it still be possible to retrieve other team members from a team in which the user is either member, admin or even owner?

Hey @mnomitch, sorry for the delay in responding to you, for some reason I didn’t see the notifications about responses to my answers.

re: the user profile - while the user profile pages are going to be preserved temporarily, we’re actually deprecating the link responses in our APIs as a privacy-preservation step.
re: the avatar link - we’re just saying don’t try to reconstruct the URL from its constituent components, because we will likely change it as we rework our URL structure.
re: URL slugs - we are planning a transition from username-based repo slugs to workspace-name repo slugs, but will transition all existing username values to a parallel workspace, to ensure backwards compatibility. Our recommendation here is the same as the avatar-link though, don’t try to construct the URL from username or workspace name. Relying on the UUID will ensure that the URLs are always valid even if the user changes their workspace or username.
repository.full_name- For now all of these responses won’t be UUID based, and when we move from Username -> Workspace, the url structure will essentially be preserved.

Let me know if you need any clarifications.

Your friendly PM resource,
Jarred

1 Like

@jcolli2 can you also reply to my question?

If you’re asking if the team/username/members endpoints will still work to pull in members of teams, the answer is yes. It looks like there is a mistaken deprecation notice on that endpoint, sorry if that caused some confusion.

If that’s not what you mean, let me know and I’ll try to get more specific.

1 Like

Thanks! That is really helpful to know

Is there any way to force this new behavior on bitbucket cloud? make it actually fail if we are referencing the wrong urls? A header or something?

Need clarifications regarding bitbucket repositories API. Does it preserve username path parameter or it MUST be replaced by account_id or uuid of the user?

In gdpr api changes announcement it says

We are excluding repo URLs from this deprecation to avoid breaking repo references. As part of giving users better control of their data, we are going to separate references to user-spaces from content-spaces, which will preserve existing repo URLs.

This tells me GET /2.0/repositories/vivek is going to work post April 29th when GDPR is enforced.

However, migration guide contradicts it by saying other than teams all /username/ in path parameter should change to uuid or account_id.

Please clarify as it has impact on bitbucket Jenkins integration.

Also is there way to enforce GDPR behavior, e.g. by sending HTTP header, like we can do with JIRA cloud?

Summary

This text will be hidden