Important Update Effective February 1, 2024!
Due to recent changes in Jira and Confluence, we've made the tough decision to discontinue the OpenID Connect (OIDC)/OAuth app and no longer provide new versions for the newest Jira/Confluence releases as of January 31, 2024.
This is due to some necessary components no longer shipping with Jira/Confluence, which would require some extensive rewrites of the OIDC App.
Important Update! This app will be discontinued soon!
Due to recent changes in Jira, which no longer ships with some components required for our Read Receipts app to run, we've made the tough decision to discontinue the app, as of Februar 5, 2025.
Important Update! This app will be discontinued soon!
We've made the tough business decision to discontinue the app, as of January 11, 2025.
What information do we store on our servers
What data do we have access to?
When you install a Jira Cloud add-on the add-on can request certain 'scopes' of access. For the Out-Of-Office Assistant case, we require the following scopes:
- READ,
- WRITE,
- DELETE,
- ACT_AS_USER
- 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. The wide use of rights is necessary because the app has to assign issues and comment on the users behalf. And it should not just act as user, as then the assignments and comments would look like they come from the user himself, which proofed to be disturbing. However, we DO NOT STORE any information obtained by these means from the Jira cloud database.
When an app is installed, we do store a public and secret key in our database. We store this so that our app 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 app for Jira Cloud.
Full disclosure here - we could 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 not done so yet. If we ever need to, for example in order to debug an extra tricky problem, we will also ask for your permission first before performing these requests.
In the context of the Outlook integration:
- Scope: Mailbox Settings
- Retrieved data: User, Automatic Replies Setting
What data do we store in our database?
Information stored by the app to make the product work
We try to store as little identifying information about your data (issues, projects etc) as possible in our database. Things we do store:
- The clientKey of your Jira Instance,
- A JWT keypair
- Audit log entries
- We store what you see in the audit log UI basically. Issue keys & ids, assignee account 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).
All the information about out of office rules is not stored on our servers but in the user data space of your Jira user. We advise to read Atlassian's Privacy Policy to better understand how your personal data will be stored in Jira and how you can exercise your rights.
In the case of integrations, we store the tokens and IDs required for exchanging information with the third party service. For Microsoft Outlook, this implies:
- access token (encrypted)
- refresh token (encrypted)
- Outlook Client ID
- Outlook User ID
- Scope
Information stored in our CRM that is necessary to conduct our business
Additionally, we store the following information in our CRM system for each installation of our app:
- Billing Contact (name and email)
- Technical Contact (name and email)
Note that this information is not at the user level: we only have one contact per installation, and often times the information provided is a shared email account like billing@acme.com.
This information is provided by the customer to Atlassian as part of their Jira setup and provided to us via REST APIs queries to the Atlassian Marketplace. We store it in our CRM and use it for the purpose of communicating with customers and evaluators for the duration of a commercial relationship.
Resolution generally does not conduct lead generation activities, and we do not proactively reach out to customers based on the information provided by them during an evaluation with the purpose of conducting pre-sales activities. Occasionally, we may include past evaluators that closed their trial up to 6 months prior in communications about new functionality. The information is then retained for reporting and data consistency reasons.
We treat customer privacy and security seriously. We believe in full transparency 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 how long do we retain your data?
All personal data in our databases is removed or anonymized after a year counting from the last commercial interaction with the customer. We do not count our own outreach activities like emails as such interactions, but we do count any interaction of the customer with our support and marketing teams, regardless of whether an evaluation or commercial license of the product is active at that time.
How can you request to access, transfer, or delete your data?
- The app access scopes can be revoked at any time simply by disabling/uninstalling our add-on in your Jira instance. This is the case with all Connect apps, so not special to us.
- Requests for accessing or deleting your data can be sent to atlassian.apps@resolution.de with the subject "Data protection request", in particular with regards to technical and billing contacts stored in our CRM. However, note that the deletion of these contacts in our systems will not alter the original data, which will remain available on Atlassian's database.
- Requests for transferring personal data to another systems are best addressed to Atlassian, as they do store information for each Jira user and we do not.
More information
More general information about how we treat your personal data can be found in the general Data Protection Statement.