Fisheye and Crucible: Right to rectification


Under Article 16 of the GDPR, you have the right to have inaccurate personal data rectified. The GDPR requires that you take reasonable steps to rectify the individual's personal data where requested.  An example of such a request may be an individual requesting their display name be updated to reflect a name change.  Whether or not modifying personal data stored within the product is within the scope of reasonable steps required to honor the individual's request will vary on a case-by-case basis, and is determination you should always make with the assistance of legal counsel.  Once you have determined you have an obligation to rectify personal data, we have provided the following instructions on how to do so within certain Atlassian products.  

Personal data stored within the product can be divided into one of two areas: 1) account-level personal data; and 2) free-form text.  Account-level personal data are data fields that exist within the product for the sole purpose of identifying an individual throughout the product.  Examples of account-level personal data include the user's display name, profile picture or avatar and email address.  These data elements are generally visible from the user's profile and are used throughout the product to point back to the user's profile when the user is @mentioned or tagged on in certain spaces or content.  Changing account-level personal data elements will automatically populate that change throughout the product where the relevant account-level data elements appear. 

If you have included personal data in free-form text, either typed into content spaces or as a custom field label, you will need to use the product's global search feature to surface this personal data and recitfy it on a case-by-case basis.    


Any user can view and edit their personal data from within the Fisheye and Crucible user interface. However, depending on how a user's details are populated or configured by an administrator, that experience might differ.

Version compatibility

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


Personal data in "structured" data

User profile data in an Internal Directory

Where Fisheye and Crucible users are managed and stored within an Internal Directory, each individual can view and edit their own personal data.

User profiles can also be edited by Fisheye and Crucible administrators.


  • a username can only be changed by the administrator.

User profile data in an External Directory

Fisheye and Crucible can be integrated with an external directory (LDAP/Crowd/Active directory) and users can be managed there. That integration is in read-only mode so Fisheye and Crucible users can only view their personal data from their user profile page. This information can only be modified by an administrator. 

Personal data in free-text data

Fisheye and Crucible can store free-text data in various locations like review details, objectives and comments. Personal data can also be retrieved from connected repositories. Please see the Fisheye and Crucible: Right to erasure for more information on how to modify this data.


Personal data can be stored in places within Fisheye and Crucible that can't be modified. 

Application logs

Fisheye and Crucible stores information in log files, which is useful in case of an error or a problem occurs at the application level. 

Any personal information stored in the logs cannot be modified. Read more in Fisheye and Crucible: Right to erasure.

Repository data

Fisheye and Crucible can index repositories. Data retrieved from the repository cannot be changed, due to possible data corruption. Information has to be changed in the repository first. Please see the Fisheye and Crucible: Right to erasure for more information on how to modify this data.


Administrators can create backups of all data stored in Fisheye and Crucible (including personal data), and this can be used to restore Fisheye and Crucible on another instance, with the same dataset. This data cannot be modified because significant effort would be needed to unpack the archive and update/remove all data in the exported XML files. How these backups and the data they contain is governed is up to each administrator and their respective organizations to decide.

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 Nov 19, 2018

Was this helpful?

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