Preparing for JIRA 7.9

This page covers changes in JIRA 7.9 that can affect add-on compatibility and functionality. This includes changes to the JIRA platform and the JIRA applications (JIRA Core, JIRA Software, JIRA Service Desk).

As a rule, Atlassian makes every effort to inform add-on developers of known API changes. Where possible, we attach release targets. Unless otherwise indicated, every change on this page is expected to be released with the first public release of the JIRA Server 7.9 products. We also make release milestones available prior to the release:

• For JIRA Server, the JIRA development team releases a number of EAP milestones prior to the final release, for customers and developers to keep abreast of upcoming changes. For more information on these releases, see JIRA EAP Releases.

• For JIRA Cloud, the JIRA team releases updates to the JIRA Cloud products on a weekly basis. Add-ons that integrate with the JIRA Cloud products via Atlassian Connect should use JIRA REST API.

We will update this page as development progresses, so please stay tuned for more updates. We also recommend following the JIRA news on Atlassian Developer blog for important announcements and helpful articles.

Summary

The risk level indicates the level of certainty we have that things will break if you are in the "Affected" section and you don't make the necessary changes.

Changes

Asynchronous cache replication in JIRA Data Center

We've changed the way cache is replicated in JIRA Data Center, making the replication asynchronous. Previously, we replicated each modification immediately after it occurred (synchronous). Now, we're adding each modification to a persistent queue and replicating it to other nodes after it's promoted to the top of the queue. Thanks to that, replication occurs in the background and is independent of any of your further actions in JIRA.

This approach improves the scalability of the cluster, and also helps us remove cache inconsistencies between the nodes. After being added to the queue, a modification will remain there until it's successfully replicated to other nodes. When one of the nodes goes offline, the replication to this node will be stopped, and resumed after the node goes back online again, ensuring that not a single modification gets lost.

Although the replication occurs in the background and is invisible to you and your users, it should slightly increase the disk space needed in the local home directory on each of your nodes. The queued modifications are stored in the local home until they're successfully replicated. Our tests have shown, however, that a queue typically is 10 MB in total. Mind that there would be a separate queue for each of your nodes.

Improved Kanban boards (JIRA Software)

We're limiting the number of issues displayed in the Done column on the Kanban board. Instead of cluttering the board with issues that are already completed, we're showing only issues that were updated in any way within the last 2 weeks. Any project admin can disable this feature, or change the retention period (Board > Configuration > General). Limiting the number of displayed issues should speed up your board significantly (depending on how many issues you have).

Microsoft SQL Server 2016

We've added another supported platform - Microsoft SQL Server 2016.

Wildcard search for version fields

JIRA 7.9 brings searching through version fields with a wildcard. Here are some details about this feature:

Operators:

• CONTAINS (~) operator. It will behave differently than for the text fields (finding an exact match, not a fuzzy match).
• Asterisk (*) to specify the location of unknown characters.

Fields:

• Fix version
• Affected version
• Custom fields using the Version Picker

Examples:

• fixVersion ~ "9.*" will find all issues from the 9.x line.
• fixVersion ~ "*9*" will find all issues that contain "9".

Empty JQL queries

Some of our users reported performance problems with their boards and gadgets, which were caused by filters using empty JQL queries. Running an empty JQL query retrieves all issues existing in your instance, which can seriously affect performance in large instances. To avoid that, we've added an option that lets you decide how an empty JQL query behaves: either returning all possible issues (like it is now), or no results at all. This option is available as one of the global settings (Administration > System > General configuration).

Important: If users choose to disable empty JQL queries, it might affect plugins that use such queries to "get all" on purpose. If you're a plugin developer and your plugin uses empty queries, you should change them to proper ones that retrieve accurate results. If you're a JIRA admin planning to disable empty JQL queries, make sure to check that plugins in your instance are not affected.

New events in the audit log (JIRA Software)

We've added the following events to the audit log:

• boards (created, deleted)
• sprints (deleted)

Delimiters for CSV (JIRA Software)

We've added an option that lets you choose one of the four most commonly delimiters when exporting your issues to CSV. These are comma, semicolon, vertical bar, and carret. An extra dialog showing these delimiters will be displayed every time you export search results to CSV (run a search, and then click Export > CSV). If you've automated exports or are running a lot of them, you can disable the extra dialog in global settings. If you disable it, comma will be used as the default delimiter.