This article contains the answers to the most popular questions in regard to how our Jira Cards integration is built. For general information please see here.
1. How does Jira-Miro authentication go exactly?
- The protocol used is OAuth 1.0. Currently, Atlassian supports only this protocol. OAuth 2.0 authorization code grants (3LO) is currently in developer preview.
2. Is data secured in transit between Jira and Miro?
- We use the TLS security protocol. It encrypts HTTP messages before transmission and decrypts messages upon arrival.
3. Can we have a diagram showing the data flow between Jira and Miro, such as during authentication, normal usage, etc.?
- The detailed info can be found in this Jira Developers article. We implement our integration according to Atlassian documentation.
4. Is it possible to save search queries (using advanced search) in Miro?
- We are showing in a Jira picker the queries that are added to favorites in Jira by the Jira System Admin who set up the integration.
5. Will the cards work with Jira Datacenter?
- Yes. We are approved by Atlassian and we already have a lot of customers successfully using Jira Cards with Datacenter. The installation procedure is the same.
6. How is the token handled?
- The token persists for 5 years unless revoked. We cannot change the token's expiration date, as this policy is defined on the Atlassian side. You can revoke the token on the Jira side using web UI. Keep in mind that each new token stops the integration from working and requires reconnecting it on the Miro side (click the Connect button when setting up the integration).
7. What endpoints does your integration use?
POST /rest/webhooks/1.0/webhook
POST /rest/api/2/issue - create new issue
PUT /rest/api/2/issue/id - update issue
GET /rest/api/2/user/picker?query=xx
GET /rest/api/2/myself
GET /rest/api/2/filter/favourite
GET /rest/api/2/issue/picker
GET /rest/api/2/serverInfo
GET /rest/api/2/issue/$key
GET /rest/api/2/issue/createmeta
GET /rest/api/2/issue/$key/editmeta
GET /rest/api/2/priority
GET /rest/api/2/issuetype
GET /rest/api/2/mypermissions
8. Will Miro create a webhook per team or per project?
- A webhook is created during the team authorization with Jira, so the webhooks are created per team.
9. Will Miro retain any of the customer’s Jira data? If yes, how long is the retention period and how will the data be secured?
- Yes, Miro retains the card's data which are added onto the board. Also, the data are updated if the webhooks are configured during JIRA cards plugin setup process. The retention period is unlimited. Only the general Miro account security protocols are applied.
10. Is a single access token used for all of the customer’s Jira access, or separate tokens used for individual users/project?
- We use the single access token of the JIRA administrator who has enough security privileges to setup a plugin connection. After that everyone in the Miro team account who is using the Jira cards does it on behalf of that JIRA user profile. As for the access rights to the JIRA projects and issues, it is controlled by the privileges of the JIRA user.
11. How are the request tokens, access tokens, private keys, and other OAUTH secrets/credentials secured?
- During the integration, only access tokens are used. They are securely stored within the database and are used only on the server side. The authToken is only used for the webhook. It is not the actual authentication token used by OAuth. Requests are sent over an encrypted connection. The secret key is auto-generated and is associated as per team.
12. Is there a way we can restrict the information that can be retrieved from Miro? Ie. let’s assume we only want to see the ‘title’ and ‘status‘, can we prevent the access to other fields such as ‘description’ or ‘attachment’ to any user in Miro?
- We did not find any mention in the Atlassian's documentation of how to limit the information to just a few fields.
13. Are custom Jira fields supported?
- Yes, we support almost all custom fields of basic types. If you have a complex data type field, it may not be supported.
14. Can we connect multiple Jira instances to a Miro team?
- No, it's one Jira instance per team.
15. What's going to happen with existing Jira Cards in case we switch to another Jira instance?
- Your cards will stay on Miro boards (no data loss) but they will stop updating.
16. Does Jira Cards plugin support Next-Gen projects?
Yes, it does. Please note that currently, there is no Epic link/field when creating a Jira Card for a Next-Gen project on Miro's side.
17. What's going to happen with existing Jira Cards if we move them from one Project to another on Jira's side?
Currently, when you move Jira issues from one Project to another, they no longer update on Miro's side. As a workaround, we suggest you copy a Jira issue URL (Ctrl/Cmd+C) and paste it into a Miro board (Ctrl/Cmd+V). Thus, a Jira Card will show new values and will be updated automatically.
18. What IPs are you using to communicate to the Jira system?
Our static IP addresses that we use for Jira are 52.16.47.17, 54.216.81.236, 54.217.180.21, 54.73.153.141, 34.249.78.135, 46.51.161.49, 54.217.110.122, 54.220.142.217, 54.228.53.200, 54.73.173.202, 54.73.41.83, 54.74.0.207, 54.74.167.92, 54.75.137.71. Do note that these are the addresses used only to communicate with the Jira system. Miro app's IPs are dynamic and to ensure that all the functionalities on the Miro boards (including some of those related to Jira cards) perform successfully we ask to add our domains to your allowlist.
19. If a board is moved to another Miro team, what will happen to Jira cards on the board?
- The Jira cards will stay on the board but no one will be able to modify them (even if the same Jira instance is configured for the target team). When clicking a card, you will see a message: "JIRA Card was imported from another account". If you would like to make the cards editable, please import them to the board anew.