Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

Version 1 Next »

What data do we have access to?

When you install a JIRA Cloud add-on the add-on can request certain 'scopes' of access. In Automation for JIRA's case, we require READ, WRITE and ADMIN scopes. This means the add-on is granted access to all JIRA REST APIs marked with these permissions on this page: jira rest scopes. We require this access to do things like adding comments to issues, edit issues etc.

When a cloud add-on is installed, we store a public and secret key in our database. We store this so that our add-on can make authenticated requests to your JIRA instance as well as receive authenticated requests from your JIRA instance. This is pretty standard for any Atlassian connect add-on for JIRA Cloud.

Full disclosure here - we can use the public key and secret to make authenticated REST calls to any of the REST APIs mentioned on the page linked above manually. However we have only done this in rare circumstances when we need extra information to debug a tricky support problem. We will also ask for your permission first before performing these requests. You can revoke these rights at any time simply by disabling/uninstalling our add-on in your JIRA instance.

What data do we store in our database?

We try to store as little identifying information about your data (issues, projects etc) as possible in our database. Things we do store:

  • Rule config information:
    • Rule name and description
    • Rule component config information (e.g. JQL strings used in triggers could contain project keys etc)
  • Audit log entries
    • We store what you see in the audit log UI basically. Issue keys & ids as well as any changes made to the issue shown on the left hand side in the audit log
    • We don't store full issue details. (This may change in the future to enable us to make our rule execution queue more fault tolerant, but this data would only exist for the lifetime of the rule execution).
  • Contact information for users that setup a rule
    • We store username, name and e-mail address. This is so we can send these users an e-mail in case a rule doesn't execute due to add-on licensing issues

We also collect Google analytics to better help us understand how our users use the front-end, so that we can build better features. We do not include identifying information however in these analytics (such as issue data, config data etc).

Myself and my co-founder have both worked at Atlassian for 10 years previously and we treat customer privacy and security seriously. We believe in full transparancy around these issues. As far as we are concerned, your data is yours and we do not share your data with any third parties (unless we are legally obligated to do so - however this case has not arisen yet).

For more details please also see the data privacy policy - https://codebarrel.io/privacy-policy/

If you have any further questions please don't hesitate to ask!



  • No labels