Preparing for Jira 11.2
This documentation is intended for Jira developers who want to ensure that their existing apps are compatible with Jira Software Data Center 11.2 and Jira Service Management Data Center 11.2.
Latest version
Here you can find information about the latest EAPs.
Application | Date | Number | Version (Maven) | Downloads |
|---|---|---|---|---|
Jira Software |
| 11.2.0-EAP02 | 11.2.0-m0041 | |
Jira Service Management |
| 11.2.0-EAP02 | 11.2.0-m0041 |
Summary of changes
This section provides an overview of the changes we intend to make so that you can start thinking about their impact on your apps. Once the updates are ready, we'll indicate when they’ve been implemented and in which milestone.
- Jira Software and Jira Service Management common features
- Supported platforms changes
- Welcome OpenSearch in Jira Data Center
- Indexing and snapshots improved with OpenSearch
- Implement custom query mappers for your app
- Connect securely with OAuth 2.0 for app links
- Protect your Jira nodes with JQL resilience
- Strengthen sysadmin and OS access separation BREAKING CHANGE
- Optimize your instance with safeguards BREAKING CHANGE
- One place to clean them all
- Jira Software features
- Jira Service Management features
Jira Software and Jira Service Management common features
Supported platform changes
Status: IMPLEMENTED (EAP 01)
In Jira 11.2, support for Microsoft SQL Server 2019 (MSSQL 2019) is deprecated.
Welcome OpenSearch in Jira Data Center
Status: IMPLEMENTED (EAP 01)
We’re actively working on OpenSearch performance adjustments. For example, swimlanes might load slowly on boards with more than 10,000 issues.
With the Jira Data Center 11.2 release, OpenSearch will be fully supported for production use. You can now configure Jira to use OpenSearch as your search platform, either on premises or as a managed service like AWS OpenSearch Service. Explore how to configure OpenSearch for Jira
We recommend switching to OpenSearch because it offers performance, scalability, and reliability improvements over Lucene.
To understand the differences between OpenSearch and the default Lucene search platform, review the OpenSearch for Confluence Data Center guide. While this guide focuses on Confluence, the information about the search platforms is also relevant for Jira. We're working on a Jira-specific report and will share it as soon as it's ready.
You might also want to get familiar with our previous OpenSearch documentation:
- Search API deprecations and upgrade guide for Jira 11
- Migrating FieldIndexers in Jira 11
- Migrating Lucene collectors to Search API in Jira 11
Indexing and snapshots improved with OpenSearch
Status: IMPLEMENTED (EAP 01)
When OpenSearch is enabled in Jira Data Center, you’ll notice changes to both the user interface and REST APIs. The Index Admin UI now uses a new URL (OpenSearchIndexAdmin.jspa) and offers a different set of configuration options tailored for OpenSearch.
The indexing and snapshot API endpoints now reflect OpenSearch-specific behavior.
- The reindex endpoint always performs a full background reindex:
/jira/rest/api/2/reindex
- The snapshot endpoints are disabled because they don’t apply to OpenSearch:
/rest/api/2/index-snapshot/rest/api/2/cluster/index-snapshot/{nodeId}
Implement custom query mappers for your app
Status: IMPLEMENTED (EAP 01)
You can now extend your app to support custom search operations across both Lucene and OpenSearch backends. If your app needs to translate custom query objects into search engine queries, you’ll need to implement custom query mappers for each backend.
Explore how to implement custom query mappers
Connect securely with OAuth 2.0 for app links
Status: IMPLEMENTED (EAP 01)
We're introducing OAuth 2.0 support for application links (app links) across Atlassian Data Center products. OAuth 2.0 is an industry-standard authentication protocol that enables secure, modern, and reliable connections between Atlassian products and external applications.
We’re also working on OAuth 2.0-based app links to connect with cloud to allow for secure and efficient integrations of hybrid environments, and will share the timeline soon.
Protect your Jira nodes with JQL resilience
Status: IMPLEMENTED (EAP 01)
We’re introducing JQL resilience, a set of safeguards that help prevent node crashes caused by resource-intensive JQL operations. To stop a JQL query from using too much memory or running for too long, you can:
- set a maximum search result limit.
- define a JQL query time limit to interrupt queries that run too long.
- enable a memory usage circuit breaker to reject new JQL queries when memory is low.
For each node, you can control these limits in the jira-config.properties file. Each change requires you to restart Jira for it to take effect.
When these features are enabled, some JQL searches might return a SearchException in situations you didn’t encounter before, such as timeouts. Jira logs these events and publishes them in the audit log for admins.
Adjust these limits carefully. Changing them can be disruptive and may cause unexpected behavior in your app.
Strengthen sysadmin and OS access separation
Status: BREAKING CHANGE IMPLEMENTED (EAP 01)
We’re improving Jira Data Center security by further separating product sysadmin and operating system (OS) access. This change doesn’t affect Jira Software features. In Jira Service Management, we’ve secured the Groovy Console behind the system property assets.groovy.console.enabled and added audit logging.
We’ve clarified the distinction between the global administrative permissions: Jira Administrator and Jira System Administrator. Access to sensitive features in Jira has been refined to ensure that only the appropriate roles have the required permissions.
To help you manage this transition, we've introduced a new application property: jira.strict.admin.permissions. This property lets you opt in to the updated role requirements at your own pace. It controls the following features:
- Some feature flags now require the Jira System Administrator role.
- Changing Java Management Extensions (JMX) settings now requires the Jira System Administrator role.
System administrators can update this property in the jira-config.properties file or in the advanced settings in Jira. By default, this property is set to false. This means the stricter permissions are opt-in for now, but they'll become opt-out in a future major version of Jira Data Center.
Optimize your instance with safeguards
Status: BREAKING CHANGE IMPLEMENTED (EAP 01)
Jira Instance Optimiser now includes safeguards to help you stay within recommended limits for comments, custom fields, issue types, issues, and projects. These safeguards help maintain system stability and performance as your instance grows.
To set up the limits:
- In the upper-right corner of your Jira application, select Jira administration, and then select System.
- In the sidebar, find Instance Optimizer and select Overview.
- Select Configure safeguards.
You can enable or disable safeguard enforcement, and choose whether to receive email and in-app notifications. When usage approaches a set limit, system admins receive notifications. If a user tries to perform an action that would breach a safeguard, the action is blocked and the user receives a warning.
This change might affect your app.
Make sure your app detects creation errors triggered by safeguard enforcement and shows a clear message to users if a safeguard is breached. Most safeguard enforcement is implemented at the service layer (for example, productService instead of productManager, or issueService instead of issueManager). For best integration and error reporting, your app should use the service layer where possible.
Don’t adjust default safeguard limits in production instances without consulting Atlassian support. For product testing, you can adjust safeguard limits in Advanced settings.
Set up limits using the following properties. By default, these limits are disabled.
Safeguard | Enable property | Limit property | Default value |
|---|---|---|---|
Comments per issue |
This property is set to true by default, but the Comments per issue safeguard is disabled unless restricted groups are configured. This is legacy functionality. |
|
|
Issues |
|
|
|
Issue types |
|
|
|
Projects |
|
|
|
Custom fields |
|
|
|
More about Instance Optimizer for Jira
One place to clean them all
Status: IMPLEMENTED (EAP 01)
We're deprecating the Clean up functionality in Jira Data Center and removing the Audit Custom Fields link. Instead, the cleanup features, such as project and issue archiving, are now integrated into the preinstalled Instance Optimizer app, which provides more efficient and automated ways to optimize your instance.
With this change, you’ll find all the cleanup features in one place. More about Instance Optimizer for Jira
React 18 and Atlaskit upgrade in Jira 11.2
Status: IMPLEMENTED (EAP 02)
Jira Data Center 11.2 upgrades React to version 18 and updates Atlaskit components to their latest versions. This change reduces vulnerabilities inherited from older Atlaskit packages and brings recent bug fixes and accessibility improvements to Jira.
As part of this update, several web resources have been deprecated. If your custom apps or integrations rely on these resources, check out the recommended replacements for improved performance. More about Web Resource deprecation and replacements
Jira Software features
Deprecation of Browse Project properties in workflows
Status: IMPLEMENTED (EAP 01)
Starting in Jira 11.2.0, we're deprecating the jira.permission.browse.* workflow step properties.
You can enable the com.atlassian.jira.workflow.permission.browse.removal feature flag to preview the removal enforcement.
Jira permission manager will ignore these Browse Project properties starting from version 12.0.0. To prepare for this change, you’ll need to update your workflows to use alternative such as security levels and Automation for Jira (A4J).
New limit of 10,000 items on a board
Status: IMPLEMENTED (EAP 01)
This limit applies only when you’re using OpenSearch. The default Lucene search platform isn’t affected.
With the OpenSearch implementation in Jira, Scrum and Kanban boards can display up to 10,000 items. When a board is full, an admin needs to update the board filter to reduce the number of included issues. This update helps Jira scale for large enterprises, improves search performance, and prevents indexing bottlenecks.
To check the total number of issues on your board, go to Issues, then select Search for issues and apply your board’s filter.
Read our community blog about the boards limit
Jira Mobile plugin removal
Status: IMPLEMENTED (EAP 01)
In Jira 9.11, we deprecated support for the Jira mobile web interface. Now, in Jira 11.2, we’re removing the Jira Mobile plugin in favor of the Jira Data Center mobile app for iOS and Android.
Jira Service Management features
New REST API scopes for service accounts
Status: IMPLEMENTED (EAP 01)
We’ve added support for service accounts in Jira Service Management and Assets by introducing READ and WRITE scopes to public REST API endpoints. This update lets you control access for service accounts, so you can specify whether an integration or automation can read or write data through the API:
- Use
READfor retrieving data. - Use
WRITEfor making changes.
In this release, we’ve added the ScopesAllowed annotation. This change is part of our ongoing service accounts project for Data Center. Join the Early Access Program for service accounts
Link your Jira with Confluence through OAuth 2.0
Status: IMPLEMENTED (EAP 01)
You can now connect your Jira Service Management to the Confluence knowledge base, Assets Confluence attributes, and Assets-Confluence macro through OAuth 2.0. With OAuth 2.0, impersonation is automatic, and Jira will act as the logged-in user when making requests to Confluence.
To configure the integration, select the JSM_KB scope and set the Confluence incoming link to READ. The integration is compatible starting from the following versions:
- Jira Service Management Data Center 11.0
- Confluence Data Center 10.0
- Assets-Confluence macro 3.0.0
If your Jira and Confluence instances don't share the same userbase, avoid using OAuth 2.0, as impersonation relies on matching usernames. OAuth 1.0 connections will continue to work, but you must manually recreate the application link to switch to OAuth 2.0.