Preparing for Jira 9.11

This documentation is intended for Jira developers who want to ensure that their existing apps are compatible with Jira 9.11.

Upgrading from 8.x to 9.x triggers full Jira reindex that causes some downtime during the process. If you’re on 8.x now, make sure you’ve estimated the downtime and set the best time for the upgrade.

Learn more about how to handle full reindex and estimate downtime

Quick info

Latest version

Here you can find information about the latest EAPs.

Application/Date numberVersion (Maven)Downloads

Jira Core/Software

 

9.11.0-RC01

9.11.0-m0003


Source files (Core)

Source files (Software)

Jira Service Management

 

5.11.0-RC01

5.11.0-m0003

Source files

Summary of changes

In this section we'll provide an overview of the changes we intend to make, so you can start thinking how it might impact your apps. Once they're ready, we'll indicate when a change has been implemented, and in which milestone.

Jira automation 9.0 release

Along with upcoming Jira Software 9.11 and Jira Service Management 5.11, we’re releasing Jira automation 9.0 – an upgrade to the Automation for Jira app. Jira automation 9.0 comes with security improvements and introduces two new actions to automation rules. This version is compatible with the following Jira applications:

  • Jira Software Data Center 8.20.0 and later
  • Jira Service Management 4.20.0 and later

Mask secret keys in your automation rules

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT JIRA SOFTWARE

Jira automation 9.0 provides a new ability to hide the actual values of secret keys and URLs of external services that automation rules can call out with specific notification actions. The new feature ensures secure and uncompromised connections to external services as well as facilitates the reuse of validated secret keys across different rules and projects.

What is secret key masking about?

Before the changes, you could add a secret key or paste a URL of an external service like Microsoft Teams or Slack only when creating a notification action for an automation rule. The key or URL was displayed in plain text. That’s why other project and global admins could always see its value in an automation rule. Such visibility of sensitive information could introduce a potential security threat. Besides, the absence of a single place where all secret keys and URLs would be listed complicated their management and reusability.

We’ve considered these concerns and come up with a mechanism that will allow you to secure your secret keys, manage them confidently, and reuse them across multiple scopes.

Now, Jira automation has a new Secret keys panel where you can create secret keys, define their scopes, edit keys, or remove them. When adding a notification action that must use a secret key to an automation rule, you’ll select the appropriate key from the list retrieved from the Secret keys panel. The list will contain the names of the available keys but not their values, so the selection and reuse of keys will be secure.

What notification actions have been affected by the change?
  • Send Hipchat message
  • Send Microsoft Teams message
  • Send Stride message
  • Send Twilio notification
  • Send Slack notification
  • Send web request
How to start masking secret keys?

To start managing your secret keys in Jira automation:

  1. Upgrade the Automation for Jira app to version 9.0.

    What should I consider before the upgrade?

    If you already use Jira automation and you’re upgrading a multinode instance to Jira 9.11.0, we suggest doing one of the following to preserve the data and support the continuity of the app:

    • RECOMMENDED Upgrade the app with UPM before upgrading Jira. We recommend this option as it ensures that the affected automation rules will continue operating during the instance upgrade.
    • Disable the app before upgrading Jira and enable all nodes that are running the upgraded version.
    • Disable the rules using secrets before the upgrade.

    When the first node is upgraded, rule schemas in the database are migrated to the new format. The new version of rule configurations won’t work with older versions of the app installed on the nodes that haven’t been upgraded yet.

  2. In the upper-right corner of the screen, select Administration > System.
  3. In the left-side panel, select Automation rules.
  4. In the meatball menu, select Manage secret keys.
    Manage secret keys
  5. Select New secret to create a new secret key.
  6. In the Key name field, enter the name of the new key. When you create a notification action, you’ll select the keys by their names in the dropdown list.
  7. In the Key value field, enter the value of the new key. Secret key values never display anywhere. Even if you decide to edit the key, the Key value field will be empty. If you want to edit the key value, you’ll only need to enter the new value in the field.
  8. In the Scope field, select in what automation rules the new key will be used.

    Learn more about the scope options

    As a project admin, you can select the Single project scope to apply the key to automation rules in the project you administer.

    As a global admin, except for Single project, you can select the following scopes:

    • Multiple projects to apply the key to automation rules in the selected projects.
    • All projects to apply the key to all automation rules in your instance.
  9. Select Add. You’ve saved the key and can set it for notification actions in automation rules according to its scope.

The “Look up issues” and “Create variable” actions in Jira automation

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT JIRA SOFTWARE

Jira automation 9.0 also introduces two new actions: Lookup issues and Create variable.

Lookup issues

The Lookup issues action allows you to create a JQL query that Jira will use to search for required issues or to aggregate the search results for other actions. For example, you can set up queries to:

  • Automatically compile and send a list of issues to your Slack or email to inform stakeholders about the work progress after a sprint is completed.
  • Calculate how many issues have a particular status in a current sprint.
  • Configure a daily reminder about your team’s open stories or about issues with SLA shorter than three days.
  • Sum up the total of story points from all stories under an epic.

The data on the found issues will be stored in the smart value {{lookupIssues}}. Because {{lookupIssues}} acts like a list, all the available smart values for lists will work with this smart value. At the same time, it allows access to a limited number of fields.

Expand to check the fields that can be accessed with {{lookupIssues}}
  • {{key}} returns the issue key.
  • {{description}} returns the issue description.
  • {{url}} returns the issue URL.
  • {{summary}} returns the issue summary
  • {{assignee.displayName}} returns the assignee
  • {{reporter.displayName}} returns the reporter
  • {{status.name}} returns the status
  • {{issuetype.name}} returns the issue type
  • {{resolution.name}} returns the resolution
  • {{fixVersions.name}} returns the fix version
  • {{created}} returns the date the issue was created
  • {{updated}} returns the date the issue was updated
  • {{project.name}} returns the name of the project the issue belongs to
  • {{Story Points}} returns the story points for the issue. Since this field is a numerical value, numerical operations such as min, max, average, and sum can be executed on the smart value {{lookupIssues.Story Points}}.
Create variables

The Create variable action allows you to store the content of a smart value inside a variable that will be available within the entire scope of an automation rule, including inside branches.

For example, you can create the variable storypoints and make it accessible in the rule with the syntax {{storypoints}}. This custom smart value can be used by other actions and conditions in the same rule.

Allowlist in Jira automation is now enabled by default INCLUDES BREAKING CHANGES

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT JIRA SOFTWARE

This change might break currently configured rules if the provided URLs aren’t allowlisted.

Jira system administrators can fix broken rules by adding the URLs to the allowlist or disabling allowlist verification. We don’t recommend disabling the feature as it can pose a security risk.

Learn more about checking URLs against the Jira allowlist

To strengthen the security in Jira automation and enhance the protection against Server-Side Request Forgery (SSRF) attacks, we’re changing the way Jira handles external requests by enabling Jira allowlist by default. In Jira automation, the allowlist for sending outbound HTTP requests is always enabled in the Global configuration menu.

How this affects your automation rules

You can’t publish a rule if the URL you are requesting isn’t present in Jira's allowlist.

Automation rules that no longer work after this change can still be marked as successfully executed in the UI. To check if the rule was triggered and view its final result, inspect the audit log — if the rule doesn’t work due to allowlisting changes, you’ll see an execution error. Learn more about the audit log

If a rule is currently disabled, you won’t be able to make it active and will see the “Error 404: file not found” in the web console. Adding the requested URL to the allowlist will fix the error.

The information about allowlist settings is stored in the Application properties table on the System info page. To access the settings, go to Administration > System > System info.

Learn more about advanced Jira configuration

Removing deprecated functions from the UrlState.js DATA CENTER

Status: IMPLEMENTED (eap01)

App:  JIRA SOFTWARE

In Jira 9.9, we’ve deprecated several functions in the UrlState.js library. In this version, we’re removing them completely from the codebase:

  • isUrlStateUpToDate()
  • historyChanged()
  • logDifferenceInState()
  • init()

Make sure that you adjust your apps accordingly and don’t use these functions in your code.

Feature improvements: project shortcuts can now be reordered

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT JIRA SOFTWARE

Keep project shortcuts better organized with the new ability to rearrange them in the project sidebar. You can now make the frequently used links appear first in the list, or group them together to keep all related info in one spot:

  • drag and drop the shortcuts to rearrange
  • use the Move up and Move down buttons to change shortcut positioning in the list

  1. Project shortcuts: sidebar section where all shortcuts are located
  2. Add shortcut: create a new shortcut for the project
  3. Actions menu: reorder and manage the existing shortcuts

Learn more about managing project shortcuts

Store attachments more efficiently in the S3 object storage DATA CENTER INCLUDES BREAKING CHANGES

Status: IN PROGRESS (eap01)

App: JIRA SERVICE MANAGEMENT JIRA SOFTWARE

This feature is currently available behind the feature flag com.atlassian.jira.attachments.storage.configurable. When enabled, it introduces breaking changes to the API and might also break some Jira apps. Check what’s changed in the API

Make sure that you properly test the feature before enabling it in your production environment. Learn how to enable dark features in Jira

If you’re using Jira Software Data Center 9.11.0 or Jira Service Management 5.11.0 and running your application in AWS, you can store attachments in Amazon S3 object storage. This doesn’t apply to Asset object attachments in Jira Service Management as they’ll still be stored in Jira shared home directory.

S3 object storage offers an enhanced enterprise experience compared to the Network File System (NFS), especially for customers with large or growing data storage needs. Learn more about configuring Amazon S3 object storage

You can also store attachments in a third-party object store that exposes an S3-compatible API. However, we’re not providing direct support for attachments that are stored in an object store other than Amazon S3.

Changes to the API

Some Jira APIs aren't compatible with the introduced S3 object storage method as they expose filesystem-specific concepts such as java.io.File.

Some apps still use these incompatible APIs and may not function correctly when attachments are stored in S3. Ensure you test the apps on your instance before enabling this feature.

These APIs have been deprecated since Jira 9.7 or earlier, and most of them have alternatives documented in the Javadocs:

The following API classes may not function correctly from Jira 9.11 for instances that have configured their attachments to be stored in S3.

Expand to view API classes incompatible with attachments stored in S3

Class

Reason for incompatibility

Alternative

com.atlassian.jira.
config.util.
AttachmentPathManager

Exposes the path attachments are stored at.

The contents of this path may be migrated to S3 and therefore would become inaccessible via this class.

Use the com.atlassian.jira.
issue.AttachmentManager
directly.

If your app needs to store data unrelated to Jira attachments use <dataDirectory>/<your-plugin-key> where <dataDirectory> is the directory returned by com.atlassian.jira.
config.util.JiraHome#getDataDirectory()
.

com.atlassian.jira.
util.AttachmentUtils

Returns java.io.Files for attachments and thumbnails that are filesystem specific and allow bypassing AttachmentManager.

Instead of accessing attachment or thumbnail files directly, use com.atlassian.jira.
issue.AttachmentManager
or com.atlassian.jira.
issue.thumbnail.ThumbnailManager
to create, delete, or stream their content.

How S3 object storage is configured in Jira

S3 object storage is configured in the filestore-config.xml file that should be located in Jira <localhome>. To use S3 as a target location for attachments, the filestore attribute in the filestore-config.xml must match the s3-filestore id.

Example filestore-config.xml file configured to use S3 object storage
<?xml version="1.1" ?>
<filestore-config>
  <filestores>
    <s3-filestore id="attachmentBucket">
      <config>
        <bucket-name>jira-bucket</bucket-name>
        <region>us-east-1</region>
      </config>
    </s3-filestore>
  </filestores>
  <associations>
    <association target="attachments" file-store="attachmentBucket" />
  </associations>
</filestore-config>

If you’re already using Amazon S3 to store avatars

If you already have S3 object storage configured and want to keep attachments in the same bucket as avatars, the filestore attribute should point to the same bucket where avatars are located.

Example filestore-config.xml for storing both avatars and attachments in S3, in the same bucket
<?xml version="1.1" ?>
<filestore-config>
  <filestores>
    <s3-filestore id="jiraBucket">
      <config>
        <bucket-name>jira-bucket</bucket-name>
        <region>us-east-1</region>
      </config>
    </s3-filestore>
  </filestores>
  <associations>
    <association target="avatars" file-store="jiraBucket" />
    <association target="attachments" file-store="jiraBucket" />
  </associations>
</filestore-config>

To use separate buckets for attachments and avatars, define multiple <s3-filestore> elements and reference each of them in the respective association targets.

Example filestore-config.xml for storing both avatars and attachments in S3, in separate buckets
<?xml version="1.1" ?>
<filestore-config>
  <filestores>
    <s3-filestore id="avatarBucket">
      <config>
        <bucket-name>jira-avatar-bucket</bucket-name>
        <region>us-east-1</region>
      </config>
    </s3-filestore>
    <s3-filestore id="attachmentBucket">
      <config>
        <bucket-name>jira-attachment-bucket</bucket-name>
        <region>us-east-1</region>
      </config>
    </s3-filestore>
  </filestores>
  <associations>
    <association target="avatars" file-store="avatarBucket" />
    <association target="attachments" file-store="attachmentBucket" />
  </associations>
</filestore-config>

Updated layout in the table with custom field contexts

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT JIRA SOFTWARE

The UI for this feature is still a work in progress and to offer the best possible user experience, it is not currently available by default. To access the new functionality, turn on the jira.customfields.configure.modern.ui feature flag.

Learn how to enable dark features in Jira

To better organize content in the table with custom field contexts, we've modified its structure so that the key configuration details appear in one place. You can now find the Default value, Options, and other field properties in a single Configuration column.

  1. Contexts tab that lists all contexts configured for the “Development team” custom field.
  2. Configuration column that presents all configuration options in a particular context.

Currently, all configurations are fully displayed in the Configuration column to help you quickly scan the content without expanding a particular setting. 

If you’d like to share your feedback on this behavior or the functionality in general, let us know in the comments under this announcement: Jira 9.11 EAP 01 has been released!

Improvements to the support zip creation

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT JIRA SOFTWARE

In this release, we’ve revamped the process of creating a support zip in the Atlassian Troubleshooting and Support Tools (ATST) app. The Create a support zip page got a new design and enhanced functionality:

  • Users are now able to pick one of 4 file size limitation options (25/100/500 MB per file)
  • Added an option to select logs based on the last file modification date: any time, today, or in the past 3/5/10 days
  • The default maximum file size is now 100 MB per file
  • Added new API parameters to support File modification date and Maximum file size options
  • After creating a zip, the customization preferences are saved and shared across the instance

  1. Verify the contents of your zip file
  2. Customize the contents of your zip file
  3. Create a new support zip on this node

Learn more about creating a support zip

Project permissions get extended configuration DATA CENTER

Status: IMPLEMENTED (eap02)

App: JIRA SERVICE MANAGEMENT JIRA SOFTWARE

After this update, some users might not see every person that was previously displayed in Assignee, Reporter, and user mentions.

If you don’t want to have this update immediately and need to adjust the project permissions first, disable this feature flag: com.atlassian.jira.ignoreBrowseUsersPermissionsInUserPickers. To use the updated functionality, just enable the flag again.

Learn how to manage dark features in Jira

To enhance the privacy and security of your project information, we’re making changes to the project permissions that’ll give your more granular control over the level of data displayed to users.

You can now set up more “contextual” browsing within the project by defining user visibility in mentions, Assignee, and Reporter pickers. This lets you disclose the key information needed to complete a task, without giving users full permissions in the project.

What has changed

We no longer check the Browse users permission for User mentions (@user) as well as Assignee and Reporter pickers. Instead, we validate the following permissions of a user that's interacting with the pickers or wants to mention someone:

  • Assignee: a user needs to have the Assign issue permission to interact with the picker and change the assignee. This picker will now show all users that have the Assignable user permission in the project.
  • Reporter: a user needs to have the Modify reporter and Browse projects permissions to interact with the picker and change the reporter. The picker will show users with Browse projects permission in the project.
  • User mentions: a user needs to have the Browse projects permissions to mention other users on issues. The picker will show users with Browse projects permission in the project.

Based on these permissions, we define whom the user will see in these pickers and mentions.

The pickers and mentions will also work for anonymous users if those users have proper access to the project. For bulk edit operations that include issues from multiple projects, only users that have appropriate permissions to all of these projects will be displayed.

Learn more about project permissions and how to configure them

Boosting Jira’s resilience to database connectivity dropouts

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT JIRA SOFTWARE

We’re introducing a fix that will retain a scheduled job until the restart even if your Jira loses a database connection while this scheduled job is starting (for example, a mail queue or an automation rule).

As soon as the connection resumes, the job will automatically restore, start, and properly schedule for the next occurrence. You’ll no longer have to restart the whole instance or a node where the connectivity dropped.

User session invalidation across the cluster without the system reboot DATA CENTER

Status: IN PROGRESS (eap01)

App: JIRA SERVICE MANAGEMENT JIRA SOFTWARE

User sessions will now be invalidated cluster-wide, without restarting Jira, after the following local events occur:

  • A user changes their password.
  • An admin changes a user’s password.
  • An admin anonymizes a user.
  • An admin deletes a user.
  • An admin ends a user’s session across the cluster through a REST API on any node.

The session invalidation events are now propagated across the multinode setup environment, ensuring that a user session will be invalidated not only on a node where the event occurred. This approach not only guarantees security by consistently invalidating sessions, but it also allows you to effectively manage user access in instances where an excessive number of requests from a single account may be contributing to performance deterioration.

How does an admin end a user’s session through a REST API?

To end a user’s session across the cluster, send the DELETE request to the following REST endpoint: api/2/user/session/{username}. username is the username of the user whose session you’re invalidating.

The response won’t contain a body but can return one of the following statuses:

  • 200 if the operation is successful.
  • 401 if you aren’t logged in.
  • 403 if you don’t have permission to perform the operation.
  • 404 if a provided username wasn't found in Jira.

Secure your sensitive data with AWS Secrets Manager DATA CENTER

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT JIRA SOFTWARE

We’re adding support for AWS Secrets Manager, which is also in development for the releases of Bitbucket Data Center 8.13 and Confluence Data Center 8.6.

Secrets Manager is a powerful tool from Amazon Web Services that provides secure storage for sensitive data, like database credentials or security keys. Avoid storing plaintext passwords in configuration files and rest assured that your secrets won’t be exposed to any vulnerabilities.

Secrets Manager stores sensitive data in the cloud and returns them with a call from an access method. Rather than using hard-coded credentials, Secrets Manager lets you retrieve sensitive information programmatically through an API call that uses IAM (Identity and Access Management) roles to ensure the validity of the call.

New infrastructure metrics for in-product diagnostics

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT JIRA SOFTWARE

We’re adding a number of new metrics for monitoring the health and performance of your instance infrastructure:

  • outgoing and incoming mail servers
  • external user directories
  • shared and local home directories
  • node communication for Data Center instances.

Learn more about the new infrastructure metrics

We’ve also implemented a new health check for the stability and security of the connection between your Jira instance and the supported user directories.

Learn more about the health check

Link multiple Confluence spaces to a single portal DATA CENTER

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT

We’re introducing the ability to link more than one knowledge base space to a single service project. This feature will improve your customer service experience and reduce request turnaround times, as agents and customers can access a wider range of articles for self-service. 

Project admins can now link multiple spaces from the same Confluence instance, and agents can choose the appropriate space when they create new articles. We’re also making some UI changes to the agent view to enhance the knowledge base search and article creation experience. Learn how to set up a knowledge base

Project settings page linked to multiple spaces

What do I need to know?

  • You can link up to 10 spaces in each service project.
  • If you’ve linked more than 10 spaces from a Confluence Data Center and Server version earlier than 8.5.0, the knowledge base search results may not be comprehensive as the search query string is limited to 255 characters.
  • If you’ve linked multiple spaces from a Confluence Data Center and Server version earlier than 8.5.0, the restrictions icon won’t be displayed for restricted articles.

Get data for any time slice DATA CENTER

Status: IN PROGRESS (eap01)

App: JIRA SERVICE MANAGEMENT

We’re introducing flexible date ranges in the reporting functionality. Project admins and agents can now analyze data for custom time periods by selecting specific date ranges in addition to the preset options. What's more, you are no longer limited to just the past year – you can report data for any 12-month period that you need. Learn how to create custom reports

Article effectiveness report with custom date range

New editor in Assets

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT

We’re updating the editor in Assets to create a modern and consistent experience across Assets and the rest of the Jira Service Management UI. The updates also allow you to consistently apply text color and format text as code. We’re rolling out these changes to object comments and the post-function email templates. To check out the new editor, add a comment to an object or create a new post-function email template.

Updated editor in object comments

Improved search experience on the Customers page

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT

We’re improving the search experience on the Customers page and making the messaging displayed during search request timeouts clearer. The current message indicates that there are no customers added to the project, which isn’t accurate. In the new experience, project admins will be directed to refine their search criteria and the search bar will be available for retrying.

Read-only access to Assets information for Confluence users

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT

We’re improving the security of Assets data by strengthening the access pattern – unlicensed users can now access Assets data only when authorized through application links. With this change, Confluence users will have view-only access to Assets data through the Assets - Confluence Macro app without the need for a Jira Service Management license.

Breaking changes to Assets APIs in previous releases

App: JIRA SERVICE MANAGEMENT

Breaking changes to Assets APIs in previous releases may have caused some issues for our app developers as we missed communicating these changes. We have now added the information to the following release notes.

Learn more about breaking changes to the ObjectBean class

Learn more about breaking changes to the groupId artifact

Accessibility improvements for low-vision and keyboard-only users DATA CENTER

Status: IMPLEMENTED (eap01)

App: JIRA SERVICE MANAGEMENT

We’re bringing more accessibility updates for screen reader and keyboard-only users. The highlights of this release include improved announcements for help center errors, column headers when you switch between them, and the Activity section in issues. We’ve also improved the experience of reaching the show-and-hide toolbar element.

Check out the full list of fixed issues

Prepare to upgrade to the upcoming version of the Assets - NVD Integration app

App: JIRA SERVICE MANAGEMENT

National Vulnerability Database (NVD) are decommissioning the current API (1.0) used in the Assets -NVD Integration app. Assets - NVD Integration Versions 1.3.12 and earlier will not be able to import data into Assets after the API has been decommissioned.

We’re working on integrating the new API (2.0) from NVD so Assets can continue to import data into Jira Service Management. Stay tuned for the upcoming version of Assets - NVD Integration to upgrade. We’ll add documentation on the upgrade steps when we release the new version of the app.

We’re keen to hear your feedback on the new capabilities released with Jira Software 9.11 and Jira Service Management 5.11. Would you like any additional features or improvements to them? Use the Provide feedback about this article link at the bottom of this page to share your thoughts with us.

Last modified on Aug 29, 2023

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.