This page explains what kind of your data RaleyApps add-ons can access and how they handle and store it.
Our Notifications add-on is installed with READ, WRITE, ADMIN, ACCESS_EMAIL_ADDRESSES and ACT_AS_USER permissions in atlassian-connect descriptor, which means that it can do the following with your JIRA :
READ: issues, projects and versions from your JIRA .
WRITE: Raley Notifications can add comments to your JIRA issues when "Audit enabled" is turned on for specific notifications. The content of the comment is a textual value of notification that Raley sends out for this issue.
ADMIN: reading data of JIRA user and retrieving emails of members of specific JIRA group(s).
ACCESS_EMAIL_ADDRESSES: retrieve ALL email addresses for all accounts in your Jira
ACT_AS_USER: approve or decline JSM service requests on behalf of specific user
If you're using sending to Slack or HipChat then Raley will store the credentials you provide from those messaging platforms which are necessary to send the notifications. It does not read any data from Slack or HipChat.
If you're (like most people, actually) use Email-based notifications then:
- if using your own SMTP outgoing mail server that requires authentication, then we will store necessary user and password to send emails from it.
- if you rely on Raley-provided outgoing SMTP server then notifications will be send via Mandrill app on behalf of Raley Notifications (firstname.lastname@example.org)
We do not persistently store the details of your JIRA issues/projects/versions on our servers.
All communication between your JIRA and Raley Notifications is secured by combination of SSL and JWT. We regularly backup your notifications configuration and store them for at least 30 days.
Our IntakeForms add-on is installed with READ, WRITE and ADMIN permissions in atlassian-connect descriptor, which means that it can do the following with your JIRA:
READ: issue and projects meta information from your JIRA necessary to create issues.
WRITE: create issues (potentially, with attachments) in JIRA based on the form configuration that you set up.
ADMIN: create customers in your JIRA ServiceDesk, obtain information about your JIRA project metadata
We do not store the data submitted via Raley IntakeForms and do not read issues from your JIRA.
All communication between your JIRA and Raley IntakeForms is secured by combination of SSL and JWT. The form is rendered in IFrame and src is HTTPS protected.
We regularly backup your notifications configuration and store them for at least 30 days.
Data storage and access
Raley cloud apps are hosted on digitalcloud.com and Amazon AWS servers. Physically, data centers are located in Amsterdam and USA. Access to the Raley servers and data
is strictly limited only to RaleyApps support team. Our support team periodically inspects servers and data stored to troubleshoot issues and monitor application
Data collected during the use of Raley AddOn will not be shared with third parties except as required by law.
When you uninstall this AddOn, all of the data you provided to us will be immediately removed.
RaleyApps with Server hosting
Our Raley Notifications add-on for JIRA / ServiceDesk is an application that resides on your host JIRA server. It has access to the following data:
- single issue (and attachments) by key/id and multiple issues by JQL. For latter Raley uses "jirassimo" user to perform a query, thus, you can finely tune data access by configuring access permissions for "jirassimo" user.
- Notifications configurations and the actual emails sent by AddOn if auditing is enabled on specific configuration
Data storage and access
Raley Notifications keeps all of its configuration in the host JIRA server and does not interact to the other systems (except Email/Slack/HipChat as configured). No data is send to any third party by this add-on. RaleyApps team does not collect any data from installations of Raley Notifications.
Raley Notification does not provide any in-build facility for data backup. Instead it relies on back up of host JIRA database to restore it's function in case of disaster.
Effective as of October 1, 2015.