Fisheye and Crucible: Data protection by design and by default

Introduction

Article 25 of the GDPR sets forth the principle of data protection by design and by default. This is a broad principle with varying meaning and application depending on the context and type of personal data being processed. This principle is unique to each organization, and should always be evaluated with the assistance of legal counsel to determine all efforts required to comply. These efforts may include ensuring certain third party applications you use to process personal data are configured to default to the most privacy-friendly settings available whenever personal data is input. Below is a summary of relevant settings and configurations available through certain Atlassian products, and a discussion of any limitations. 

Description

Fisheye and Crucible is primarily a team collaboration tool, so many of the settings are open by default. There can be multiple sources of personal data stored in Fisheye and Crucible, like:

  • user profile
  • reviews
  • repository data

For a more comprehensive list, please read Fisheye and Crucible: Right to erasure


Version compatibility

All workarounds are compatible with Fisheye and Crucible Server 4.1 and later.


Workaround

Anonymous access

By default, Fisheye and Crucible permit access to all users, even users who aren't logged in. This access can be revoked by an administrator by following the steps at Configuring anonymous access

Public sign up

By default, Fisheye and Crucible allow anyone to create an account. This feature can be disabled by an administrator by following the steps at Configuring public sign up.

Emails

A user has no control over the emails they receive from, and generate to, other users triggered by the actions they take within the product. However, only users with Fisheye and Crucible accounts will receive emails.

Restricting profile viewing

Any logged in user can view another Fisheye and Crucible user's profile (including, username, display name, email).

Administrators can disable a user's email from displaying by doing the following:

  1. Go to Administration > Security Settings > Authentication > Email Visibility.
  2. Select the option Hidden beside visibility of users' email addresses. 

Restricting viewing user list

Administrators can change the visibility of user lists (global and repository) by doing the following:

  1. Go to Administration > Security Settings > Authentication > User List Visibility
  2. Select the option Hidden beside visibility of user lists. 

Restricting access to the user list, doesn't prevent users from being found through search, or a direct link.

Restricting viewing repository data

Administrators can restrict access to all repositories or a specific repository, by assigning permissions to users/groups. Please read Managing your repository for steps on how to do this.

Fisheye has no control over the information obtained from external repositories. It is the job of the administrator to know what personal data is stored in the repository and who can access it.

Author mapping

Fisheye automatically maps users to repository authors based on their username and email. This has several consequences:

  • Users are mapped even if they don't have access to the repository. They will be listed in the repository activity (visible to anyone with access to the repository).
  • Automatic mapping can't be deleted. The only option is to change a user's details.

Fisheye also allows mapping of users with authors of changesets in the repository, please read Author mapping to learn more. Administrators can disable this option by following the steps at Configuring user managed mappings. Administrators can only modify explicit mappings, automatic mappings can't be disabled.

Restricting viewing project data

Administrators can restrict access to a particular project by changing the permission scheme linked to that project.

Projects have the option to store revisions under review. If that option is enabled, all users with access to the project can see revisions (and commit authors) added to the review even if they don't have access to the repository.

Limitations

  1. There's no functionality that allows restricting access to a single profile.
  2. There's no option to disable automatic author mapping.

Additional notes

There may be limitations based on your product version.

Note, the above-related GDPR workaround has been optimized for the latest version of this product. If you are running on a legacy version of the product, the efficacy of the workaround may be limited. Please consider upgrading to the latest product version to optimize the workarounds available under this article.

Third-party add-ons may store personal data in their own database tables or on the filesystem.

The above article in support of your GDPR compliance efforts applies only to personal data stored within the Atlassian server and data center products. To the extent you have installed third-party add-ons within your server or data center environment, you will need to contact that third-party add-on provider to understand what personal data from your server or data center environment they may access, transfer or otherwise process and how they will support your GDPR compliance efforts.

If you are a server or data center customer, Atlassian does not access, store, or otherwise process the personal data you choose to store within the products. For information about personal data Atlassian processes, see our Privacy Policy.

Last modified on May 11, 2018

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.