On December 13th, Queues for Jira & JSM will be migrated to Forge. We are making this transition to ensure the app continues to meet the highest standards of security, performance, and long-term reliability. Forge provides enhanced security, a modern cloud architecture, and improved stability, which allows us to keep delivering the best possible experience.
The migration will be performed automatically by us, and will take place during the maintenance window:
December 13th, 19:00 - December 14th, 03:00 (UTC)
If your app is migrated successfully, you will not see any blocking screen and the application will continue working normally.
However, if something prevents the migration from completing correctly, you will see a dedicated screen informing you that additional steps are required before you can continue. This is the same screen described in the ‘Why do I see the Deviniti Queues are unavailable. Update the app message and what should I do?’ section.
If the screen appears, you may need to complete one of the migration options or contact our Support team.
Jira provides an API for storing application-level configuration. Queues for Jira & JSM uses these properties to control certain modules and behavior.
As part of the migration from Connect to Forge, we implemented an automatic migration of these settings.
Automatic Migration:
If the automatic migration fails, the app will still work, but none of the global configuration settings will be transferred. In such cases, the app will run using default values, and you may be presented with the troubleshooting screen.
There are two types of migration involved in this process:
If you see the message ‘Deviniti Queues are unavailable. Update the app.’ on the main Queues view your instance is likely still running the old version of Queues. This means the app version migration could not be completed, and you must update the app manually.
If the App Properties migration fails, the app will still load, but it will start with default settings. In this case, you will not see the update screen on the main Queues view. Instead, only the Configuration page will show a migration screen allowing you to retry the App Properties migration or restart the setup form.
After the version migration is completed (performed by us during the maintenance window), the App Properties migration will run automatically when your instance picks up the new version.
As part of the migration from Connect to Forge, the URLs used by the app will change. If you have saved any old links or bookmarks, you will need to update them after the migration. All new URLs will be available once you install the latest version of the app.
It depends on whether you have the browser tab open or hidden. The table below presents the approximate time of refresh.
| Rate type | Default rate when tab is visible | Tab is not visible |
|---|---|---|
| queueCountNotUpdatedRefreshRateMs | 1,5s | x2 |
| queueCountLeastUpdatedRefreshRateMs | 1,5s | x2 |
| openQueueRefreshRateMs | 20s | x2 |
There are no restrictions on the number of queues you can have in the Queues for Jira & JSM app. Although the app does not impose any restrictions in this regard, a potential issue could arise with the overall performance of the application and Jira itself, as an increased number of configured queues leads to a higher volume of refresh requests sent to Jira. The reason is that Queues for Jira & JSM are refreshed in the background, which involves sending appropriate JQL requests to Jira to retrieve the current number of tickets shown in each queue.
Furthermore, in cases of extensive configurations, organizing queues into distinct folders that users can expand or collapse as needed may be beneficial.
It’s possible to control performance parameters by changing its properties in exported .json file.
Back to App page
"performance" is on the same level as "queuesConfig". "performance": {
"queueCountRefreshOn": true,
"queueCountNotUpdatedRefreshRateMs": 1500,
"queueCountLeastUpdatedRefreshRateMs": 1500,
"queueCountCacheExpireTimeoutMs": 120000,
"openQueueRefreshRateMs": 20000
},
Version of the file has changed. Property performance will be read from a new version.
How it works?
If you meet the problem with Jira performance, you may need to change some of the default parameters which our app uses.
In order to preserve data that otherwise would be lost after you refresh the page, we use LocalStorage to store information for each queue about how many issues are in the queue and when those issues were last counted.
After each refreshing a page with queues, the total number of issues in each queue is uploaded from the LocalStorage.
Those values are uploaded only when the timeout (in miliseconds) from queueCountCacheExpireTimeoutMs property has not expired. If the time passed, it means that the value from the LocalStorage is no longer up-to-date therefore it won’t be displayed. The total number of issues in these queues will have to be counted anew.
Be careful with increasing queueCountCacheExpireTimeoutMs, because the higher it is, the higher risk that those values are no longer up-to-date.
The most expensive operation is to display the total number of issues in each queue on the list of queues.
To decide whether queues list should be refreshed or not, you can change the value of queueCountRefreshOn property to either true or false. This parameter implies whether the following properties are enabled.
The queueCountNotUpdatedRefreshRateMs property indicates time in which the algorithm searches for a queue whose total number of issues hasn’t been refreshed at all. Once all total numbers in queues have been counted (even if the queue is empty, which means the count is equal 0), the algorithm searches for a queue that hasn’t been refreshed the oldest using queueCountLeastUpdatedRefreshRateMs property and recalculates this number.
At the beginning, we recommend to increase these two properties twice in order to reduce number of requests sent by our app to Jira.
The openQueueRefreshRateMs property indicates the time in which the currently opened queue is refreshed.
{
"queuesConfig":
[/* yours queues config */],
"performance": {
"queueCountRefreshOn": false
},
"version": "3.0"
}
If you want to extend the time for properties: “queueCountNotUpdatedRefreshRateMs” and “queueCountLeastUpdatedRefreshRateMs”, type target values as in example below:
{
"queuesConfig":
[/* yours queues config */],
"performance": {
"queueCountRefreshOn": true,
"queueCountNotUpdatedRefreshRateMs": 10000,
"queueCountLeastUpdatedRefreshRateMs": 20000
},
"version": "3.0"
}
To see the custom avatar you set for your Atlassian account in our app, go to the top-right corner of the Jira top navigation, click Your profile and settings > Manage account > Profile photo and header image > Who can see your profile photo?, and select Anyone.
Now, go back to the app and enjoy your custom avatar.
Go to the documentation to learn more about updating your Atlassian account profile and visibility settings.
Atlassian introduced the App access rule, which, when applied by the admin or organization in a specific project, results in losing access to its content.
Read more about the App access rule in the Atlassian documentation.
These are names referring to the types of permissions:
When third-party cookies are blocked in the Chrome browser, Queues for Jira & JSM cannot be loaded. As a result, a blank page is displayed. To fix this problem, follow the below steps:
Currently, when Queues for Jira & JSM is installed, the JSM Default Queues view in the Service Management project remains enabled.
These two views are distinct, and replacing the JSM Default Queues with our application is not possible. This is a limitation imposed by Atlassian, as they do not permit hiding or substituting this view. To minimize confusion, our app is named, by default, Deviniti Queues, so that the functionality offered by us can be clearly differentiated from the JSM Default Queues.
Keep in mind that you can personalize the name of Queues for Jira & JSM, so it is even easier to identify it.
Sometimes, a firewall may block the application, preventing it from functioning properly on your instance. To resolve this issue, please refer to this article.
Cloud pricing is subscription based. You are eligible for support and automatic version updates as long as your subscription is active.
When your subscription renews each month, you are automatically billed for host products and apps based on the number of users in your instance.
If app pricing changes after your initial purchase, there’s a 60-day grandfathering period during which you can renew based on the old pricing.
Apps are billed based on the number of users in your host product. Jira Cloud apps are priced based on the maximum users of the Jira products on your instance. For example, if you have Jira Software (50 users) and Jira Service Management (10 agents) on the same instance, you pay the 50-user price for apps.
The pricing structure for cloud products and apps is as follows:
If you’ve opted for annual billing for your host product, apps are also billed annually at a discount (12 months for the price of 10).
Academic, community and open source licenses are not available for cloud apps.
For cloud apps, you cannot extend your free evaluation period. All cloud apps are immediately subscribed by a user, and we provide a free evaluation period. This is a minimum of 30 days and ends on the second billing cycle after you first subscribe to the app.
Licenses for Atlassian apps are essential for maintaining access to features and receiving the latest updates. The consequences of an expired license can differ based on whether you’re using a trial version, a commercial license for the Cloud, or a Data Center instance. Read this article to learn more about this topic.
For all the details about the licensing of cloud apps, refer to this article.
If you can’t find the answer you need in our documentation, raise a support request.
Include as much information as possible to help our support team resolve your issue faster.
