This page explains what kind of your data RaleyApps add-ons can access and how they handle and store it.
Raley Emails Notifications
Our Notifications add-on is installed with READ, WRITE, ADMIN and ACCESS_EMAIL_ADDRESSES 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
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 (email@example.com)
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.
Authentication with GMail OAuth 2
Raley Emails Notifications for Jira/JSM can send emails from your GMail account on your name. For that it requires that you grant us access scopes:
The first scope, as name implies, is needed to send an email message under your name. The second scope (https://www.googleapis.com/auth/gmail.metadata) is required to retrieve the metadata of the email we've just sent to get the value of Message-ID header. We're storing the value of Message-ID on our side to refer to other emails (using References header) that were sent for the same Jira/JSM ticket. This allows for a beautiful threaded view of all emails sent by Raley for specific Jira/JSM ticket.
The app is sending emails directly and not from the Drafts folder. For sending, we need to know your GMail name and your GMail email which you provide during configuration of GMail OAuth2 outgoing email server in Raley.
You connect your GMail account with the JSM to pick up new emails and create support tickets from them - this is JSM standard functionality (Email Requests). Raley allows you to connect the same GMail mailbox for sending outgoing emails. As a result - all your ticketing is happening via a single GMail account and thus greatly enhances user experience for your JSM users (customers).
We store user’s name and email address as you provide those during GMail Oauth2 configuration in Raley. These values are used to send emails from the given GMail account.
Raley Emails Notifications for Jira/JSM’s use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
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.
Raley Purchase Orders
Our PurchaseOrders app is requiring the following permissions through atlassian-connect descriptor:
READ: issue-related information to create and manage purchasing workflow
WRITE: to transition issue in workflow
ADMIN: read project and workflow-related information to manage PO statuses, information about your Jira users to handle your organization structure and users rights
ACCESS_EMAIL_ADDRESSES: to send email notifications to Jira users when their approval of a Purchase Order is needed
Raley PurchaseOrders stores information about your workflow statuses, existing project keys and issue keys. Other issue-related data is not stored.
We also store all the quantitive information about purchase orders like lines, amounts and summaries.
We do not store private user information.
All the data stored in Raley PO is regularly backed up and stored 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 November 4, 2022.